Fail2ban: A Crude and Dumb Yet Surprisingly Effective IPS

Before implementing Fail2ban, it’s important to have a basic understanding of how it works, what I’ll be showing you, and why I’m showing you certain things. If you already know this stuff, then feel free to skip this section. You can skip to How Does Fail2ban Help or Installing Fail2ban if you don’t care about the background information.

The Problem With Scrapers

If you’ve spent any time hosting a web server or any other service on the public internet, you’ve probably noticed stuff like this in your logs:

<Redacted IP> - - [19/Oct/2025:23:18:33 +0000] "GET /ALFA_DATA/alfacgiapi/radio.php?bx=0e215962017 HTTP/1.1" 404 548 "-" "Mozilla/5.0 (Linux; Android 11; Redmi Note 9 Pro Build/RKQ1.200826.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/90.0.4430.210 Mobile Safari/537.36" "<Redacted IP>" "<Redacted IP>"
<Redacted IP> - - [19/Oct/2025:23:18:33 +0000] "GET /ALFA_DATA/alfacgiapi/404.php?bx=0e215962017 HTTP/1.1" 404 548 "-" "Mozilla/5.0 (Linux; Android 11; Redmi Note 9 Pro Build/RKQ1.200826.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/90.0.4430.210 Mobile Safari/537.36" "<Redacted IP>" "<Redacted IP>"
<Redacted IP> - - [19/Oct/2025:23:23:36 +0000] "GET /con.php HTTP/1.1" 404 548 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" "<Redacted IP>" "<Redacted IP>"
<Redacted IP> - - [19/Oct/2025:23:23:36 +0000] "GET /con.php HTTP/1.1" 404 548 "www.google.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" "<Redacted IP>" "<Redacted IP>"

While there’s lots of friendly scrapers, which will typically obey robots.txt, there are many more crudely written ones that are simply trying to brute-force a bunch of URL’s, hoping to find sensitive information or an exploit. These scrapers are ran by an infinite variety of people, ranging from middle schoolers trying to impress their friends after learning about Kali Linux, those trying to mine crypto or build a botnet, or more recently, thanks to the AI boom, AI crawlers DDoS’ing websites (Exhibit A, Exhibit B).

Some of these scrapers are smart, some of which I’ve observed myself, but the vast majority of them are just running through a list of hosts, probably some of which come from places like Shodan to narrow their search, test a bunch of URL’s, and report back their findings. Hell, I still see several that don’t even bother changing their user agent from something like python-requests, use an empty user agent, or even whatever tool/script they’re using.

Why Even Care?

Reading through this, you might be tempted to ask yourself “There’s nothing of interest on my website. Why even bother?”, which is a very valid question.

The biggest issue with scrapers is that even if they’re not doing anything malicious, they’re still wasting resources on your web server. Your web server still has to accept that scraper’s request, send back a partial or even full response, and log it. Rinse and repeat with several scrapers doing this multiple times a day, it adds up to a lot of wasted resources. It’s significantly less resource intensive to simply blackhole all traffic from that IP address rather than having your web server respond to it.

Another issue is that they might not be doing anything malicious today, but there’s a chance that they do find something, or a vulnerability comes out for something that you’re hosting (Log4j, for example). Best case scenario, you’re getting trolled or mining crypto for someone. Worst case scenario, your server is now being used as a relay to commit federal crimes, you’re now part of a nation-state operated botnet, and the feds (Along with your hosting provider) are now after you. It’s probably a good time to mention that you should check your backups.

Regardless, the biggest thing is that it helps cut down on resource usage, and it helps mitigate against future vulnerabilities.

How Does Fail2ban Help?

The reason why I described Fail2ban the way I did is because its operation is very simple, yet surprisingly effective. All Fail2ban does is look in a log file for failed requests within a certain time period (By default it’s the past 10 minutes), and if there’s enough matches, then it’ll block that IP address.

Even though it’s very simple and arguably kind of crude, it still works surprisingly well. Even with smarter bots that try to mix in legitimate requests, presumably to try and fool proper IPS’s, Fail2ban still blocks them, since it only cares about failed requests made within a certain time.

There Are Still Flaws

Despite the simplicity of Fail2ban bringing some advantages, the simplicity also brings some downsides. For example, since Fail2ban doesn’t care about any other requests, if legitimate users are causing 4xx errors on your web server, which can simply be caused by static assets getting updated, but old ones are still cached, their IP addresses might still get banned. Fail2ban is more simple to configure than a proper IPS, but it still requires some tuning and false positives.

Another issue that Fail2ban has is when using it with Cloudflare, there might be a delay between Fail2ban banning the IP and it being banned in Cloudflare. In my experience, Cloudflare seemed to block IP’s pretty much instantly, but your mileage may vary. This might be a problem depending on your use case, but as long as you have some sort of rate limiting, and tell Fail2ban to multiply ban times for repeat offenders, then it shouldn’t be an issue. Plus, most bots are slow by design to evade rate limiting.

Cutting To The Chase: Installing Fail2ban

Now that I’ve gotten the long enough introduction out of the way, let’s actually start setting up Fail2ban. First, install the fail2ban and iptables-persistent packages:

sudo apt install fail2ban iptables-persistent

Basic Configuration

Most of the default options that Fail2ban ships with are fine, but there’s a few changes you’ll want to make.

Database Purge

The first thing that should be changed is the dbpurgeage setting. By default, it purges the database after just one day, which is pretty much useless for blocking repeat offenders. Even though you can directly modify fail2ban.conf, it can cause some headaches with major distro upgrade (Like upgrading from Debian 12 to 13), so you’ll want to create your own in fail2ban.d.

First, create your custom configuration file, using whatever name you want:

sudo nano /etc/fail2ban/fail2ban.d/fail2ban.conf

Next, add the following content, setting dbpurgeage to whatever you see fit:

[DEFAULT]
dbpurgeage = 1y

You can set it to some absurdly high number like 99y to effectively disable it, but IP addresses do change hands (Even if not frequently, especially for more simple bots), and it prevents your database from growing out of control. I personally have it set to one year. You can find all available options in /etc/fail2ban/fail2ban.conf, but make sure to make your changes in your custom configuration file.

Nginx 4xx Filter

Even though Fail2ban ships with filters for Nginx, I prefer making my own filters, since for me at least, the ones Fail2ban ship with are not all that intuitive to implement. Plus, most other places I see seem to recommend creating your own filter rather than using the included ones.

Create a new file named something like nginx-4xx.conf in filter.d, and add in the following content:

[Definition]
failregex = ^<HOST>.*"(GET|POST).*" (400|401|403|404|444) .*$
            ^<HOST> - \S+ \[\] "[^"]*" 400
# Adjust the line below as needed. You might want to include paths where static assets and dynamic content might be stored to prevent false positives.
ignoreregex = ^<HOST>.*"(GET|POST).*(favicon|apple-touch-icon).*" (401|403|404|444) .*$

Notice the second line in our failregex:

^<HOST> - \S+ \[\] "[^"]*" 400

This is taken directly from the included nginx-bad-requests.conf filter. This regex blocks requests that are either empty, or are just encoded garbage like this one:

<Redacted IP> - - [17/Nov/2025:19:04:28 +0000] "\x16\x03\x01\x05\xA8\x01\x00\x05\xA4\x03\x033\x89\x7F\xD58\x0FG\xFD\xCD\xB6b\xFE*c\x97" 400 150 "-" "-"

We can add both regex’s to the same filter, so that way anything that matches one of those regex’s will be part of the same jail.

I highly recommend using the fail2ban-regex command and regex101.com to fine tune your filter before implementing it:

sudo fail2ban-regex /var/log/nginx/access.log nginx-4xx

Jail Configuration

Like with fail2ban.conf, most of the defaults Fail2ban ships with in jail.conf are fine, but there are a few things that you should change.

First, create a new configuration file in jail.d called wordpress.conf (Or a different name if you desire). This is also where our jails for Nginx will live:

[DEFAULT]
# Somewhat randomizes ban times, so just put a random number here.
bantime.rndtime = 86400
# If you don't have a machine with a different public IP address to test, leave ignoreip blank. Set this to your own IP once you're done testing.
ignoreip = 5355:4253:4352::4942:4534:4d4f:5245/64 1.2.3.4
# How long to ban for the first time.
bantime = 5m
# How far back to look in the logs.
findtime = 10m
# How many failures until the IP is banned.
maxretry = 5

The settings for bantime, findtime, and maxretry are fairly conservative, but you’ll want to fine tune as needed. I set maxretry to 5 because I noticed that most bots seem to make at least around 5 requests, but it’s not so low that it could ban legitimate visitors. When testing, I recommend starting with more conservative settings, or at least not setting any actions when banning the IP.

Under the settings for your jail, add in the nginx-4xx jail:

[nginx-4xx]
enabled = true
port    = http,https
logpath = /var/log/nginx/access.log
# Keep this line commented out for testing, or at least make sure you can directly access your servers console in case you lock yourself out.
#action = iptables-allports

Finally, restart the Fail2ban service, and check the status of the jail with the following command:

sudo fail2ban-client status nginx-4xx

To test if it works, you can either just run watch with fail2ban-client, and start typing in invalid URL’s until you see your IP banned:

sudo watch -n 1 fail2ban-client status nginx-4xx

Or you can run something like nikto, which will also test the second regex:

nikto -h https://your-domain-or-ip

Just make sure to disable any rate limiting before running nikto, otherwise you’ll be blocked by it pretty much instantly, which will interfere with your test.

After running your test, you should see your IP in the banned IP list:

Status for the jail: nginx-4xx
|- Filter
|  |- Currently failed: 1
|  |- Total failed:     16
|  `- File list:        /var/log/nginx/access.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     1
   `- Banned IP list:   1.2.3.4

You can also use the fail2ban-regex command with the --print-all-matched flag to see what was matched:

sudo fail2ban-regex /var/log/nginx/access.log nginx-4xx --print-all-matched

A Warning Before Continuing

Before you move on to the next step, and I can’t emphasize this enough, make ABSOLUTELY sure you either have a machine with a different IP address to test with, or have some sort of out-of-band access to your server (Most hosting providers let you access the console to your server). Otherwise, you will end up locking yourself out (Don’t ask me how I know). You should test it before enabling any actions as well, since you don’t want to ban your own IP, only to find out you’re locked out of your server and have to wait out the ban.

Enabling and Testing

Now that we’ve verified that the filter actually works, it’s time to test and see if you can actually ban IP’s. Open up /etc/fail2ban/jail.d/wordpress.conf, and uncomment the following line:

action = iptables-allports

Next, restart Fail2ban, and test again (I like using nikto):

nikto -h https://your-domain-or-ip

After running your test, not only should you see your IP address listed in sudo fail2ban-client status nginx-4xx, but your browser should timeout when trying to access your server:

As a pro tip, you can also see how long it will be until an IP address is unbanned by using sudo fail2ban-client get nginx-4xx banip --with-time:

1.2.3.4 2025-12-02 15:13:09 + 301 = 2025-12-02 15:18:10

You can either wait out the ban if it’s short enough (Or you found out the hard way that you locked yourself out of your own server), or unban your IP manually:

sudo fail2ban-client unban 1.2.3.4

Configuring Cloudflare

For those that aren’t using Cloudflare, you’re free to stop right here. But if you do happen to be using Cloudflare, the setup is a little bit more involved. This is because Cloudflare acts as a proxy, which has the side effect of hiding the IP address of your visitors, preventing stuff like iptables from working correctly.

Logging Actual IPs

When looking in /var/log/nginx/access.log, you may or may not see Cloudflare’s IP addresses rather than your visitors IP addresses. Even if you do happen to see visitors actual IP addresses, and verified that Cloudflare actually is proxying your traffic (Which I’ve personally noticed in some cases), I still recommend performing this step as a precaution.

In case anything goes wrong, I recommend first creating a backup of your nginx.conf:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

First, open up /etc/nginx/nginx.conf in a text editor, and add the following content in http under where the include lines are:

http {
	...
	# Lines shown for reference, don't add these or anything above
	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;

	# This is the stuff you add
	# Creates another log file identical to the default one, just with the visitor's actual IP address
	log_format  wordpress  '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for" "$http_cf_connecting_ip"';

	access_log /var/log/nginx/wordpress.log wordpress;

	# Sets the real IP header coming from Cloudflare's IP address ranges. Make sure these are up to date
	set_real_ip_from 173.245.48.0/20;
        set_real_ip_from 103.21.244.0/22;
        set_real_ip_from 103.22.200.0/22;
        set_real_ip_from 103.31.4.0/22;
        set_real_ip_from 141.101.64.0/18;
        set_real_ip_from 108.162.192.0/18;
        set_real_ip_from 190.93.240.0/20;
        set_real_ip_from 188.114.96.0/20;
        set_real_ip_from 197.234.240.0/22;
        set_real_ip_from 198.41.128.0/17;
        set_real_ip_from 162.158.0.0/15;
        set_real_ip_from 104.16.0.0/13;
        set_real_ip_from 104.24.0.0/14;
        set_real_ip_from 172.64.0.0/13;
        set_real_ip_from 131.0.72.0/22;
        set_real_ip_from 2400:cb00::/32;
        set_real_ip_from 2606:4700::/32;
        set_real_ip_from 2803:f800::/32;
        set_real_ip_from 2405:b500::/32;
        set_real_ip_from 2405:8100::/32;
        set_real_ip_from 2a06:98c0::/29;
        set_real_ip_from 2c0f:f248::/32;
	real_ip_header X-Forwarded-For;

# Make sure you add everything above this bracket
}

Even though they rarely change, depending on when you view this post, the IP ranges shown might be outdated. You can find Cloudflare’s latest list of IP ranges here.

Run sudo nginx -t to test the configuration, and if it’s successful, restart Nginx. If there’s any issues, make sure that your indentation is right and that you added everything in the right place. You can also revert back to the old configuration by running sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf.

Pro Tip

So that way attackers can’t bypass Cloudflare and access your server directly, I recommend configuring your server’s firewall to only allow Cloudflare’s and your own IP addresses. That way, even if attackers did find out your IP, they won’t be able to do much with it.

Banning IPs

Now that we’ve gotten the logging situation under control, it’s time to figure out how to actually ban IP’s. Even though nginx can see your visitors IP addresses, iptables and whatnot can’t, so we’ll need to ban them from Cloudflare. Plus, it takes that load off your server.

Getting an API Key

To allow Fail2ban to talk to Cloudflare, you’ll need to get an API token. First, navigate to the API Tokens section on your Cloudflare profile (Link here), and click the blue Create Token button:

Next, scroll to the bottom, then click the blue Get Started button next to Create Custom Token:

Under Permissions, you’ll want to configure them as shown in the screenshot, and set Zone Resources to only include your domain. I recommend restricting the IP addresses that can use it to your server’s IP address and your own public IP:

Even though you technically can add multiple domains under Zone Resources, I recommend just creating an API token for each domain. This helps improve security (Or at least make you feel better), and provides a little bit more control.

After choosing your permissions, scroll to the bottom and click Continue to Summary, then Create Token. Your token will be displayed. I recommend keeping it somewhere safe for reference:

I also recommend using the provided curl command, ideally from your server, to test and see if the token works correctly.

The last step is to get the Zone ID of your domain to feed to Fail2ban. It’s as easy as running the following command, substituting in your own API token:

curl https://api.cloudflare.com/client/v4/zones -H "Authorization: Bearer 46616b65436c6f7564666c617265415049546f6b656e"

Assuming that you’ve restricted it to a single zone, the output will only show the information for that zone. The Zone ID will be right at the top:

{"result":[{"id":"4e6f476f7653656372657473546f4265466f756e64","name":"alexshomenetwork.com","status":"active","paused":false,"type":"full","development_mode":-12441583,
...
# You'll see a bunch of stuff, but id and name are the only things you'll need

Configuring Fail2ban

Now that you’re armed with the necessary information from Cloudflare, it’s time to configure Fail2ban. First, open /etc/fail2ban/action.d/cloudflare-token.conf in a text editor, navigate to the following lines, uncomment cfzone and cftoken, and add in your Cloudflare Zone ID and API Token:

# The Cloudflare <ZONE_ID> of the domain you want to manage
#
cfzone = 4e6f476f7653656372657473546f4265466f756e64

# Your personal Cloudflare token.  Ideally restricted to just have "Zone.Firewall Services" permissions
#
cftoken = 46616b65436c6f7564666c617265415049546f6b656e
# There are several other options you can configure. For example, you can change cfmode from block to js_challenge to show a challenge rather than outright blocking an IP

Save and exit the file. Since this file contains your Cloudflare API token, and it’s world-readable by default, you’ll want to change the permissions to more restrictive ones:

sudo chmod 640 /etc/fail2ban/action.d/cloudflare-token.conf

Next, open /etc/fail2ban/jail.d/wordpress.conf, change logpath to /var/log/nginx/wordpress.log, and add cloudflare-token under action:

[nginx-4xx]
enabled = true
port    = http,https
logpath = /var/log/nginx/wordpress.log
action = iptables-allports
        cloudflare-token

After saving and exiting, restart the Fail2ban service.

Testing (Again)

These changes won’t do us any good if we don’t know that they work, so we’ll need to run a quick test.

First, navigate to your Cloudflare dashboard, click on your domain, navigate to Security Rules under Security, then scroll to the bottom. The IP access rules will appear under Managed Rules:

Next, on your server’s console, run sudo watch -n 1 fail2ban-client status nginx-4xx to see in real time if your IP address was banned, since it might be slow to show up on Cloudflare.

I’m sure you already know this by now, but as another warning, make sure you don’t lock yourself out of your own server.

Finally, run the same tests that you did earlier, either using nikto, or doing it the manual way. After your IP address appears in the banned IP list, refresh the Cloudflare security rules page, and you should see your IP address listed under IP access rules:

When you try accessing your website, you should see a page that looks something like this:

If you’re not blocked, make sure that the correct IP address was blocked. Even though for me it blocked the IP instantly, you might need to wait a minute.

To make sure that Fail2ban can unban an IP, which shouldn’t be an issue since you’ve already banned one, run the following command:

sudo fail2ban-client unban <your IP>

Refresh the page, and the IP access rule should be gone.

Troubleshooting

If Fail2ban is able to ban your IP address, it’s showing up in the banned IP list, but Cloudflare isn’t blocking you, there’s a few things that you should check.

The first thing you should do is check and see if the IP address is banned in Cloudflare. If it’s showing up, make sure that the IP address that was banned is the same one that you’re testing from. Make sure that it isn’t a private IP address. I mention this because it’s something that’s very simple but also very easy to forget.

If you don’t see an IP access rule, then it might be a permissions issue on your API token. To verify this, open /etc/fail2ban/fail2ban.d/fail2ban.conf, and add the following line:

loglevel = DEBUG

You’ll want to remove this once you’re done, since this will flood your log files.

After restarting the Fail2ban service, open a separate terminal, and follow /var/log/fail2ban.log:

sudo tail -f /var/log/fail2ban.log

If you see something like this when banning an IP in your logs:

'{"success":false,"errors":[{"code":10000,"message":"Authentication error"}]}'

This indicates a permission issue with your Cloudflare API token. Unfortunately, this error doesn’t give much information, nor do the audit logs in your account. You can run the same curl command that Fail2ban does to see if you get the same error (Substituting in your own information):

curl -s -X POST "https://api.cloudflare.com/client/v4/zones/4e6f476f7653656372657473546f4265466f756e64/firewall/access_rules/rules" -H "Authorization: Bearer 46616b65436c6f7564666c617265415049546f6b656e" -H "Content-Type: application/json" --data '{"mode":"block","configuration":{"target":"ip","value":"1.2.3.4"},"notes":"Fail2Ban nginx-4xx"}'

If the command works, verify that the information in /etc/fail2ban/action.d/cloudflare-token.conf is correct. If the command gives the same error, check and see if your API token has Read access for Zone, and Edit access for Zone Settings and Firewall Services. You can also remove the IP addresses under Client IP Address Filtering and set Zone Resources to include all zones for testing.

Using the same command that I showed earlier, verify that you have the correct zone ID:

curl https://api.cloudflare.com/client/v4/zones -H "Authorization: Bearer 46616b65436c6f7564666c617265415049546f6b656e"

If all else fails, or you’re not positive that the API key is correct (And you didn’t save it anywhere), you can generate a new one with the same permissions by using the Roll function:

Conclusion

So that’s how you use Fail2ban with Cloudflare and Nginx to ban potentially malicious visitors from your website. Despite it being very simple and arguably kind of hacky, it’s still a surprisingly effective security measure, especially against more simple bots, which you’re most likely going to encounter.

If you have any comments, suggestions, questions, complaints, or anything else to say, feel free to leave them in the comments, and I’ll try my best to address them.

Why Wait so Long to Publish?

Some of you might have noticed that the timestamps shown in my examples at the beginning are from October, then further down one shown in November, and the date that this blog post was published is in December.

If you’re wondering why it took so long to publish this post, especially because I promised I would make it “soon” in my previous post, this is simply because of several personal issues cropping up, eating away at the time I had to work on this post. Since my two options were either to wait, or rush out something half-baked, I decided to wait and polish it up.

The post Using Fail2ban With Nginx and Cloudflare on Debian 13 appeared first on Alex's Home Network.

The Purpose of This Post (Not Important)

When I make a post on here, I like focusing on more niche and interesting stuff, or at least guides that are difficult to find elsewhere. You might be asking yourself “If you like focusing on more niche stuff, then why are you writing yet another WordPress installation tutorial?” The answer boils down to these two reasons:

1. In 2022, I wrote a series of guides about installing WordPress on Debian 11 (Part 1, Part 2, Part 3, and Part 4). However, they were my first ever blog posts, and looking back at them now that I’m much more experienced, I’m not happy about them, so I’ve been wanting to make an updated version of them.
2. I plan on using this guide as a reference for future and much more interesting posts, and I don’t want to direct people to my old, outdated, and not very good posts.

Now that we’ve got the “Why?” out of the way, let’s move on to actually installing WordPress.

Prerequisites

Before you can install WordPress, it’s important to get a few things out of the way:

• Make sure that your Debian install (Or Ubuntu, or similar) is up to date.
• This guide is written with the assumption that you’re running a bare-bones Debian 13 install with nothing else running on it, so if you’re running other services, the configuration you’ll need might be different.
• Since this is a very easy thing to overlook, make sure that whatever ports you’ll need are open on your system and on any firewalls in between (80 and 443 for WordPress, 8080 for phpMyAdmin, change as needed), otherwise you’ll spend way too much time troubleshooting.
• If you use Ubuntu, you can check if UFW, the default firewall, is enabled by running sudo ufw status. Debian doesn’t seem to have a firewall installed. You can allow a port by running sudo ufw allow 80, for example.

Installing Nginx

No good website is complete without a web server, so all you need to do to install Nginx is run the following command:

sudo apt install nginx

Next, enable Nginx to run at startup:

sudo systemctl enable --now nginx

The command should complete successfully. Type the IP address or domain of your server into your web browser, and you should see the default welcome page:

If you don’t, check to see if Nginx is running correctly:

sudo systemctl status nginx

You should also check the log files in /var/log/nginx for additional information.

And of course, check that any firewall running on your server or any firewall between your client and server is not blocking anything. You can run curl http://127.0.0.1 and curl http://ip-or-domain on your server to see if it’s a server or network issue.

Nginx Configuration

Now that you’ve verified that Nginx is working, remove the default virtual host to prevent any conflicts:

sudo rm /etc/nginx/sites-enabled/default

I recommend just deleting the symlink in /etc/nginx/sites-enabled rather than also deleting the default virtual host in /etc/nginx/sites-available, just to keep it as a reference and for troubleshooting.

Next, create a new virtual host file:

sudo nano /etc/nginx/sites-available/wordpress

And paste the following content, adjusting as needed:

server {
	listen 80 default_server;
	listen [::]:80 default_server;

	root /var/www/html/wordpress;

	index index.php index.html index.htm index.nginx-debian.html;

        # We will come back to this later when we configure Certbot for HTTPS, but for now, a catch-all is fine
	server_name _;

        # Change this to a more rational value if you want an actual limit
	client_max_body_size 999G;

	location / {
		try_files $uri $uri/ /index.php?$args;
	}

	# pass PHP scripts to FastCGI server
	#
	location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_intercept_errors on;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include fastcgi_params;
		fastcgi_pass unix:/run/php/php-fpm.sock;
		add_header X-Content-Type-Options nosniff;
		add_header X-XSS-Protection "1; mode=block";
		add_header X-Permitted-Cross-Domain-Policies none;
		add_header X-Frame-Options "SAMEORIGIN";
	}

	# YoastSEO sitemap support, it's best to remove if you don't have YoastSEO installed to prevent any conflicts

	location ~ ([^/]*)sitemap(.*).x(m|s)l$ {
		rewrite ^/sitemap.xml$ /sitemap_index.xml permanent;
		rewrite ^/([a-z]+)?-?sitemap.xsl$ /index.php?yoast-sitemap-xsl=$1 last;
		rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last;
		rewrite ^/([^/]+?)-sitemap([0-9]+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;
	}

	# Don't log access to favicon.ico and robots.txt
	location = /favicon.ico {
		log_not_found off;
		access_log off;
	}

	location = /robots.txt {
		allow all;
		log_not_found off;
		access_log off;
	}
	
	# Deny access to hidden files
	location ~ /\.ht {
		deny all;
	}
	
	# Prevent PHP from running from upload directories
	location ~* /(?:uploads|files)/.*\.php$ {
		deny all;
	}

	# Caching and gzip configuration, change as you see fit
	location ~* \.(jpg|jpeg|gif|png|webp|svg|woff|woff2|ttf|css|js|ico|xml)$ {
		expires 30d;
		log_not_found off;
	}

        # Most stuff should already be covered under gzip_types, but you can add or remove as needed
	gzip on;
	gzip_vary on;
	gzip_min_length 1000;
	gzip_types
		text/plain
		text/css
		text/javascript
		application/javascript
		application/x-javascript
		application/json
		application/xml
		application/rss+xml
		application/atom+xml
		application/xhtml+xml
		image/svg+xml
		image/x-icon
		font/ttf
		font/otf
		font/woff
		font/woff2
		application/vnd.ms-fontobject;
	gzip_proxied any;

}

This is an Nginx config that I have somewhat written myself, using the default config as a base, enabling PHP and caching support, and adding a few bits for WordPress.

After you’ve saved the file, symlink it to /etc/nginx/sites-enabled/wordpress:

sudo ln -s /etc/nginx/sites-available/wordpress /etc/nginx/sites-enabled/wordpress

Next, check to see if there’s any errors:

sudo nginx -t

If there aren’t, then you should see the following output:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Finally, restart Nginx:

sudo systemctl restart nginx

If you try accessing your server in your web browser, you’ll get a 404 error, since WordPress hasn’t been installed or configured yet. Regardless, it’ll tell you that Nginx at least sees your new virtual host.

Installing PHP 8.4

PHP is what makes WordPress tick, so we’ll need to install it. First, install the php-fpm package, along with all of the modules that WordPress needs:

sudo apt install php-fpm php-mysql php-curl php-dom php-imagick php-mbstring php-zip php-gd php-intl

Next, enable and start the php8.4-fpm service:

sudo systemctl enable --now php8.4-fpm

Configuring php-fpm

Most of the defaults are fine, but some of them need changing. For example, you can only upload up to 2MB files, which is just way too small. Here’s a couple of commands to fix that:

# Change 999G if you want some sort of limit
sudo sed -i "s/^post_max_size = 8M/post_max_size = 999G/g" /etc/php/8.4/fpm/php.ini
sudo sed -i "s/^upload_max_filesize = 2M/upload_max_filesize = 999G/g" /etc/php/8.4/fpm/php.ini

“Optimizing” pm_max_children

By default, php-fpm will only spawn up to 5 child processes, which is usually not enough for WordPress. This results in a lot of warnings in your logs saying that the limit of child processes has been reached, and can even cause performance issues.

The reason why I put “optimizing” in quotes is because there’s two ways of doing this. The first way is the right way, which involves going into www.conf, setting pm = dynamic (The default), doing some math, and setting the values based on how much memory your server has.

But since nobody wants to do math, I’ve come up with an easier way. My way involves setting pm = ondemand and pm.max_children to some absurdly high number, effectively removing the limit:

# Change 99 to something lower if you want some sort of limit
sudo sed -i "s/^pm = dynamic/pm = ondemand/g" /etc/php/8.4/fpm/pool.d/www.conf
sudo sed -i "s/^pm.max_children = 5/pm.max_children = 99/g" /etc/php/8.4/fpm/pool.d/www.conf

Next, restart the php-fpm service:

sudo systemctl restart php8.4-fpm

Now php-fpm will spawn as many processes as it wants, and thanks to pm = ondemand, it’ll terminate idle ones after 10 seconds. You’ll most likely never need to worry about it again, and your server (probably) won’t explode. My method technically causes some overhead, since it needs to keep track of those processes, but probably not enough to be noticable.

Installing MariaDB

Now that we’ve installed a web server and PHP, the last piece is installing a database for WordPress. First, install MariaDB:

sudo apt install mariadb-server

Next, enable and start MariaDB:

sudo systemctl enable --now mariadb

Then run the included script to secure MariaDB:

sudo mariadb-secure-installation

Note: Depending on your distro and MariaDB version, the command might be mariadb_secure_installation, mysql_secure_installation or mysql-secure-installation. mariadb-secure-installation is what the command is on Debian 13 and MariaDB 11.8.

On the first step, it’ll ask you for the root password on your server, but if you don’t have one and you’re using sudo instead, just press enter. You can also say no for changing MariaDB’s root user password if you’re not using phpMyAdmin, or will create a different user. For everything else, choose yes.

Installing phpMyAdmin (Optional)

Even though you don’t need phpMyAdmin, I still like having it since it makes database maintenance (if needed) easier, and it has fun statistics graphs to watch. Regardless, if you’re a command line junkie and don’t care about that stuff (And want a minimalish install), then move on to “Creating The WordPress Database (CLI)”.

First, install the phpMyAdmin package:

sudo apt install phpmyadmin

It’ll ask you a few questions during installation. The first one it’ll ask is what webserver to configure automatically. Since we’re using Nginx, don’t select anything, press tab so your cursor is over <Ok>, and hit enter:

It’ll then ask you if you want to configure a database for phpMyAdmin. Select yes, which is the default:

Next, create a password for the phpMyAdmin user (Or leave it blank to have it generate a random one:

Configuring Nginx for phpMyAdmin

Since phpMyAdmin can’t configure Nginx automatically, we’ll have to do it ourselves. First, create a new virtual host file for phpMyAdmin:

sudo nano /etc/nginx/sites-available/phpmyadmin

Next, add the following content, which spoiler alert, is basically the same as the WordPress one, just with the WordPress specific stuff stripped out:

server {
        # Change this to 80 if you want to access it with a subdomain instead
	listen 8080 default_server;
	listen [::]:8080 default_server;

	root /usr/share/phpmyadmin;

	index index.php index.html index.htm index.nginx-debian.html;

        # If you want it to be accessible on a subdomain, replace _ with your subdomain, and make sure you have a DNS record pointing to your server
	server_name _;


	location / {
		try_files $uri $uri/ /index.php?$args;
	}

	# pass PHP scripts to FastCGI server
	#
	location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_intercept_errors on;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include fastcgi_params;
		fastcgi_pass unix:/run/php/php-fpm.sock;
		add_header X-Content-Type-Options nosniff;
		add_header X-XSS-Protection "1; mode=block";
		add_header X-Permitted-Cross-Domain-Policies none;
		add_header X-Frame-Options "SAMEORIGIN";
	}

	# Don't log access to favicon.ico and robots.txt
	location = /favicon.ico {
		log_not_found off;
		access_log off;
	}

	location = /robots.txt {
		allow all;
		log_not_found off;
		access_log off;
	}
	
	# Deny access to hidden files
	location ~ /\.ht {
		deny all;
	}
}

Next, symlink it to sites-enabled:

sudo ln -s /etc/nginx/sites-available/phpmyadmin /etc/nginx/sites-enabled/phpmyadmin

Test it:

sudo nginx -t

And finally, if it was successful, restart Nginx:

sudo systemctl restart nginx

Now navigate to server-ip-address:8080 (Or your subdomain), and if everything has gone well, you should be greeted with the phpMyAdmin login screen:

Try logging in with the root user, using the password you set (Or the phpMyAdmin user, which is phpmyadmin, but you’ll need root later on), and you should be greeted with the home page:

If it doesn’t let you log in, you might need to reset the root password:

sudo mysql -e "ALTER USER 'root'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('Password') OR unix_socket;"

Or if you don’t want to use root, you can create a new user and disable the root user instead:

sudo mysql -e "CREATE USER 'notroot'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('Password');"
sudo mysql -e "GRANT ALL PRIVILEGES ON *.* TO 'notroot'@'localhost' WITH GRANT OPTION;"
sudo mysql -u notroot -p
MariaDB [(none)]> ALTER USER 'root'@'localhost' ACCOUNT LOCK;

You can perform these steps in phpMyAdmin instead, besides resetting the root password.

Additional phpMyAdmin Security

A mistake that people make far too often when configuring phpMyAdmin is leaving it wide open to the internet, and on top of that, using the default root user with a weak, or God forbid, no password. Not only can an attacker gain access to any database on your server, including your WordPress one, but it can also be used as an entrypoint to gain access to the rest of your server.

We’ve already taken half of the measures we need by locking down the root user, so let’s focus on protecting phpMyAdmin itself by requiring a separate login to access it. First, install the apache2-utils package:

sudo apt install apache2-utils

Next, create a .htpasswd file in /etc/nginx. Make sure that you choose a different login from phpMyAdmin and WordPress, otherwise it’s pretty pointless:

sudo htpasswd -c /etc/nginx/.htpasswd username

You’ll be prompted twice to enter a password. Next, change the permissions on the file to more secure ones:

sudo chown www-data:www-data /etc/nginx/.htpasswd && sudo chmod 640 /etc/nginx/.htpasswd

This will ensure that www-data, the Nginx user, is the only user that can access the file. Finally, modify the location / block in the phpMyAdmin virtual host as follows:

...
location / {
		try_files $uri $uri/ /index.php?$args;
		# Basic authentication
		auth_basic "Login Required";
		auth_basic_user_file /etc/nginx/.htpasswd;
}
...

For extra security, I would also recommend combining it with IP address rules:

...
location / {
		try_files $uri $uri/ /index.php?$args;

		# Requires that the user both has an allowed IP address and their login is correct

		satisfy all;

		# Your public IP address
		allow 1.2.3.4;
		# Your LAN (If applicable)
		allow 192.168.0.0/24;
		# You probably get the idea by now, add and remove as needed
		# Deny everyone else
		deny all;
		# Basic authentication
		auth_basic "Login Required";
		auth_basic_user_file /etc/nginx/.htpasswd;
}
...

Check your configuration and restart Nginx:

sudo nginx -t && sudo systemctl restart nginx

If all is well, try navigating to phpMyAdmin, and you should be prompted for a login from Nginx:

If you entered your login correctly, but it’s not letting you in, check /var/log/nginx/error.log and see if it’s having issues accessing .htpasswd. If it’s having trouble accessing it, you can try giving everyone access (sudo chmod a+r /etc/nginx/.htpasswd) temporarily to see if that fixes it. Giving everyone access is very insecure, so make sure to change it back once it’s working.

You can also recreate your user if you forgot your password (Or as a quick sanity check):

sudo htpasswd /etc/nginx/.htpasswd username

If you combine this with HTTPS (Certbot makes this easy) and Fail2ban (Guide here), then phpMyAdmin will be safe from the vast majority of attackers.

Creating The WordPress Database (phpMyAdmin)

After you’ve made your way into phpMyAdmin one way or another, click the new button to create a new database:

Next, enter a name for your WordPress database, and select utf8mb4_general_ci from the dropdown menu, then click Create:

Since we now need a user to securely access this database, click the phpMyAdmin in the top left corner to navigate back to the home page, then click the User accounts tab:

Under User accounts overview, click Add user account:

You can choose whatever username or password you want, but I would recommend entering localhost for Host name since that will only allow logins for that user from your server, and using the option to randomly generate a password (You’ll need to temporarily store it somewhere, since we’ll need it again):

Scroll to the bottom of the page, then click the Ok button towards the bottom left, under the SSL box:

You should be brought back up to the top of the page, and a message should appear stating that your user was created successfully.

Next, click the Database tab, select your WordPress database, then click Go:

Click Check all under Database-specific privileges to give your WordPress user full access to your WordPress database, then click Go in the bottom left corner:

Creating The WordPress Database (CLI)

If you don’t use phpMyAdmin, or just want a more straight-forward way of creating a database and user, you can more easily do it via the MariaDB command line.

First, connect to MariaDB and create a database for WordPress:

# Replace notroot with your own user, or just use sudo mysql if you didn't set a password for root
mysql -u notroot -p
MariaDB [(none)]> CREATE DATABASE wordpress;

Next, create a user for your WordPress database, and give it full permissions:

# You'll want to randomly generate a password
CREATE USER 'wordpress'@'localhost' IDENTIFIED BY 'VerySecurePassword';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost';

Now I don’t know about you, but I personally find this method a lot easier, or at least a lot easier to write about.

Actually Getting WordPress

We’re almost done with the hard part. We installed and configured Nginx, then PHP 8.4, and now MariaDB, so now that our server is setup, it’s time to actually download WordPress.

First, install a couple of packages that will let you download and unzip WordPress into your web directory. These packages might already be included depending on your distro, but for a very bare bones Debian install, they’re not:

sudo apt install curl unzip

Next, download the WordPress ZIP file. I would recommend saving it to /tmp since you don’t need to worry about deleting it, but it doesn’t matter. Just don’t forget to delete it when you’re done:

curl https://wordpress.org/latest.zip -o /tmp/wordpress.zip

Next, unzip the WordPress archive to /var/www/html:

sudo unzip -d /var/www/html /tmp/wordpress.zip

Navigate to /var/www/html/wordpress, create a copy of wp-config-sample.php, and name it wp-config.php:

cd /var/www/html/wordpress && sudo cp wp-config-sample.php wp-config.php

Next, open wp-config.php in a text editor, locate the database connection settings, and fill in your WordPress database information:

// ** Database settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );

/** Database username */
define( 'DB_USER', 'username_here' );

/** Database password */
define( 'DB_PASSWORD', 'password_here' );

/** Database hostname */
define( 'DB_HOST', 'localhost' );

Finally, change the owner of the WordPress folder to Nginx’s user:

sudo chown -R www-data:www-data /var/www/html/wordpress

Finishing The Install

Try navigating to your server’s IP address or domain like you did earlier when testing Nginx, and you should see a screen asking you for your language. Your browser may try to redirect you to HTTPS, so make sure that it’s only using HTTP:

If you see it, then congratulations! You’ve successfully finished the hard part, and can continue setting it up. If you don’t, or you’re having problems, then move to the troubleshooting sections and come back.

Click continue, and fill out your information:

After clicking Install WordPress, you should now see the WordPress admin page:

At this point, you should click on Updates under Dashboard, and make sure that everything is up to date. You should also navigate to Plugins, Installed Plugins, and click the Enable auto-updates link for every plugin that’s there. You’ll also need to do this to any new plugins that you install, since for whatever reason it’s disabled by default.

Troubleshooting

When installing WordPress, especially for the first time, there are some common issues that me (Even after doing quite a few of them) and many others run into, so I’ll outline some common issues and their solutions.

Error Establishing a Database Connection

One of the most common errors you get when setting up WordPress is that it can’t connect to your database (Usually it doesn’t display the troubleshooting steps):

The first step is to check and see if MariaDB is running, so run the following command:

sudo systemctl status mariadb

This command will also show if MariaDB is producing any errors.

The next step is to ensure that the login credentials and database name in wp-config.php are correct, and that there aren’t any syntax issues with the file. As a sanity check, you can delete the wp-config.php file and copy it again from wp-config-sample.php (Assuming you’re in /var/www/html/wordpress):

sudo rm wp-config.php && sudo cp wp-config-sample.php wp-config.php && sudo chown www-data:www-data wp-config.php

Next, it’s time to verify that your WordPress database and user actually exist. First, connect to your database using the same commands you used earlier, and run the following command to show all of the databases on your server:

SHOW DATABASES;

If you’re using phpMyAdmin, your WordPress database will appear on the left side of the screen along with all of the other databases on your server.

Next, verify that your WordPress user exists:

SHOW CREATE USER 'wordpress'@'localhost';

If your WordPress user exists, it’ll show the same CREATE USER command that you used when creating the user (The real password being replaced with a hash).

If you forgot the password you set for your WordPress user, or it happens to contain a single ' or double quote " (Which might break the syntax in wp-config.php), you can change it with the following command:

ALTER USER 'wordpress'@'localhost' IDENTIFIED BY 'VerySecurePassword';

For phpMyAdmin users, you can navigate to the same User accounts screen that you used when creating your WordPress user, and if you want to change its password, click on its name, then Change password towards the top of the screen.

Finally, to verify that your WordPress database is accessible by your user, log into phpMyAdmin or connect using your WordPress user:

sudo mysql -u wordpress -p

Then run the following commands to connect to your database:

SHOW DATABASES;
# If your WordPress database is in the list, then try using it
USE wordpress;
SHOW TABLES;
# It'll say it's empty, which is normal

If you’re getting any errors, switch back to your root account, and try giving the WordPress user all privileges on your WordPress database:

GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost';

A database permission issue may also manifest as WordPress letting you complete the setup, but it failing at installation, or otherwise giving permission issues.

If needed, update your login credentials in wp-config.php, and refresh the page. You should now be prompted for your language.

Permission Issues or Installation Failing

If WordPress is failing at the installation step, or it let you installed, but you keep getting permission errors when you try doing anything, then this can indicate a permission issue on the WordPress files, or a permission issue with your database.

First, connect to MariaDB, and try giving your WordPress user full permissions on your WordPress database:

GRANT ALL PRIVILEGES ON wordpress.* TO 'wordpress'@'localhost';

If you’re using phpMyAdmin, the steps are basically identical to creating the user, except under User accounts, you just select your WordPress user and click Database at the top.

You can try logging in as your WordPress user and try accessing the database (Which the steps for I’ve already outlined at the end of the previous section).

Next, verify that the Nginx user has access to WordPress’s files:

sudo chown -R www-data:www-data /var/www/html/wordpress

You should now be able to access WordPress without getting any permission issues.

Browser Issues (Connection Timed Out, Connection Refused)

If you try accessing WordPress, but your browser is timing out, or giving an error like connection refused, then that usually indicates a problem with Nginx.

First, make sure your browser is not trying to connect over HTTPS. Browsers like Firefox will show a warning message stating that the website doesn’t support HTTPS before letting you continue, but some browsers will redirect regardless, and fail. You might need to type in your server’s address as http://ip-address-or-domain, making sure you type http instead of https, since that usually forces browsers to use HTTP rather than HTTPS. You can also temporarily disable any features that automatically redirect you to HTTPS to ensure they’re not the problem.

If you’re behind Cloudflare or another CDN provider, they might be trying to redirect you to HTTPS, so make sure that those features are disabled. After that, try clearing your CDN provider’s cache and accessing WordPress in a private browsing session.

Once you’ve ruled out browser issues, it’s time to narrow it down to the network or your server. The easiest way to do this is to have your server send a request to itself using curl:

curl http://127.0.0.1
# Alternatively
curl http://localhost
# You can use your server's IP address or domain instead
curl http://server-ip-or-domain

You should get the response printed directly to your terminal. If it fails, check the status of the Nginx service:

sudo systemctl status nginx

If you try to restart the Nginx service (sudo systemctl restart nginx), and it fails, check your config for any errors:

sudo nginx -t

You can also check the log files in /var/log/nginx for any errors as well.

Basic Security

Since this blog post is already long enough, I will only leave a couple of security tips here that are simple to implement, yet so many people neglect to do, despite being mentioned by basically every WordPress guide.

Securing wp-admin

Despite being one of the most well known vulnerabilities of WordPress, many people still leave /wp-admin wide open to the internet, with weak credentials, and typically no security measures.

The first thing you should do is use secure login credentials. Generate a random password with special characters, and make it as long as WordPress allows.

The next thing you should do is limit access to /wp-admin and /wp-login.php. You can accomplish this by making Nginx require a separate login that’s different from your WordPress login. The steps used when securing phpMyAdmin are basically identical, but there’s still some stuff you should know.

First, install the apache2-utils package so we can create a .htaccess file:

sudo apt install apache2-utils

Next, create your user. Again, make sure that this login is different from WordPress and anything else on your server, otherwise you’re wasting your time:

sudo htpasswd -c /etc/nginx/.htpasswd username
# Or if .htpasswd already exists when we secured phpMyAdmin, name it something else
sudo htpasswd -c /etc/nginx/.something-else username

Next, change the permissions on your .htaccess file to something more secure, replacing the file name with the one that you chose:

sudo chown www-data:www-data /etc/nginx/.something-else && sudo chmod 640 /etc/nginx/.something-else

After that, open /etc/nginx/sites-available/wordpress in a text editor, and locate the location / block. Under that, add in two blocks for /wp-admin and /wp-login.php:

...
# The default location / block for reference. You don't need to add this

location / {
	try_files $uri $uri/ /index.php?$args;
}

# Again, change .something-else to the file name that you used
location /wp-admin {
	auth_basic "Login Required";
	auth_basic_user_file /etc/nginx/.something-else;
}

location = /wp-login.php {
	auth_basic "Login Required";
	auth_basic_user_file /etc/nginx/.something-else;

	# Copy the PHP stuff from the location ~\.php$ block
	# There's probably a better way to do this, but I also don't feel like figuring it out
	include snippets/fastcgi-php.conf;
	fastcgi_intercept_errors on;
	fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	include fastcgi_params;
	fastcgi_pass unix:/run/php/php-fpm.sock;
	add_header X-Content-Type-Options nosniff;
	add_header X-XSS-Protection "1; mode=block";add_header X-Permitted-Cross-Domain-Policies none;
	add_header X-Frame-Options "SAMEORIGIN";
}

For yet an extra layer of security, I recommend adding IP address rules to further restrict access:

...
# Again, probably a better way to do this, but this works fine

location /wp-admin {
	satisfy all;
	# Your public IP address
	allow 1.2.3.4;
	# Your LAN (If applicable)
	allow 192.168.0.0/24;
	# Add or remove as needed, make sure deny all is at the bottom
	deny all;
	auth_basic "Login Required";
	auth_basic_user_file /etc/nginx/.something-else;
}

location = /wp-login.php {
	satisfy all;
	allow 1.2.3.4;
	allow 192.168.0.0/24;
	deny all;
	auth_basic "Login Required";
	auth_basic_user_file /etc/nginx/.something-else;
	...
}
...

Finally, tell Nginx to test your config, restart Nginx (You probably know the commands by now), and try navigating to /wp-admin and /wp-login.php. Nginx should prompt you for a login separate from your WordPress one:

Now /wp-admin and /wp-login.php have some extra layers of security, especially if you combine Fail2ban to block brute force attacks (Guide here).

If you’ve typed in the right credentials but it’s not letting you login, check /var/log/nginx/error.log to see if it’s having any issues accessing your .htpasswd file. You can try running sudo chmod a+r /etc/nginx/.something-else (Obviously substituting with your own .htpasswd file) to see if that fixes it, but make sure to change this back since it’s very insecure.

Disabling /xmlrpc.php

The /xmlrpc.php endpoint was used by WordPress to allow applications to communicate to your website, like the WordPress mobile app for example. However, nowadays it has been replaced by the REST API (Located at /wp-json), and is only used for backwards compatibility.

Regardless, unless if you plan on using ancient applications to talk to your website, all it does is serve as a flashing neon billboard for attackers. Despite this, not only is it enabled by default, but WordPress doesn’t include an option to disable it (Which did exist in the early days after its introduction, but was apparently removed).

The two common ways of disabling /xmlrpc.php is by using a plugin, or blocking it on your webserver. I’ll be showing how to block it with Nginx, so you don’t need to install any plugins.

First, fire up your WordPress virtual host file, and navigate to right where we left off in the previous section. Under your location = /wp-login.php block, add in a new one for /xmlrpc.php:

# You can add an allow before the deny to allow certain IP's in the slim chance that you happen to need it, but you probably don't
location = /xmlrpc.php {
	deny all;
}

Test your config and restart Nginx, then try nagivating to /xmlrpc.php, like you did with /wp-admin and /wp-login.php. You should get a 403 forbidden error.

Configuring HTTPS

If you’ve made it this far, and not only your server isn’t on fire, but you haven’t gone insane (Or lost me), then congratulations! You’ve made it to the home stretch, and we only have one last step left, which is configuring HTTPS. To make it easy, I’ll show how to use Certbot.

Before we can do anything, it’s important to note that WordPress seems to listen on one URL and one URL only, and that URL is set when you first install WordPress. This means that since you’ve probably accessed your server with its IP address or http://yourdomain.com, WordPress will automatically redirect you to it.

If you try setting up HTTPS without first changing this URL, you’ll either just get redirected to your server’s IP address, or get a redirect loop since Certbot tells Nginx to redirect to HTTPS, but WordPress keeps trying to redirect to HTTP.

Thankfully, it’s easy to change this URL. You can either do this in /wp-admin under Settings and General, or modifying the WordPress database, which is what I’ll show. Keep in mind, you WILL temporarily loose access, but you can change it back if needed by modifying the database.

First, connect to your database using your WordPress user, then switch to your WordPress database:

mysql -u wordpress -p
MariaDB [(none)]> USE wordpress;

Take note of your existing URL settings so you can easily revert back to it if needed:

SELECT * FROM wp_options WHERE option_name IN ('siteurl','home');
# Your current URL will be displayed under option_value

Once you’ve taken note of your existing URL, change it to your new one:

UPDATE wp_options SET option_value = "https://changeme.alexshomenetwork.com" WHERE option_name = "siteurl" OR option_name = "home";

Now that you’ve updated your site URL’s, you can now install Certbot:

sudo apt install certbot python3-certbot-nginx

So that way Certbot actually sees your website, open your Nginx virtual host file WordPress, and locate server_name _; towards the top:

# Remember me mentioning this earlier? Change the _ you set earlier to your domain
server_name changeme.alexshomenetwork.com;
# I put my domain there just as an example

If you’re accessing phpMyAdmin from a subdomain, then your config should already be good.

You know the Nginx drill by now. It’s a good time to verify that the correct DNS records are pointing to your server, and you can actually access your server from the public internet, from both HTTP and HTTPS, otherwise Certbot will fail. If you’re behind a CDN like Cloudflare, you should disable any features that automatically redirect you to HTTPS, and purge their cache.

Next, run the certbot command, and follow the prompts. If you don’t want to do it interactively, you can use flags instead (certbot --help):

sudo certbot

Certbot should automatically restart Nginx for us, but if it doesn’t, do our ususal Nginx drill, and try accessing your website.

If you can’t access your website, you might need to purge your cache with your CDN provider like Cloudflare if you’re behind one. I also recommend checking in a private browsing session, since your browser cache can cause issues as well.

Conclusion

If your website is working, then congratulations! You’ve installed WordPress from start to finish, and even implemented some basic security measures. Like I mentioned a couple of times earlier, I do plan on writing an updated Fail2ban guide (Which I will link here). If you have any questions, feel free to leave them below, and I’ll try my best to help you, even though I can’t make any guarantees.

References

Nginx Authentication: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/

Database Creation: https://developer.wordpress.org/advanced-administration/before-install/creating-database/

Where my Nginx Config is Derrived From: https://developer.wordpress.org/advanced-administration/server/web-server/nginx/

The post Installing WordPress on Debian 13 appeared first on Alex's Home Network.

Legal Disclaimer

In case it isn’t obvious, the stuff that I’m showing in this post is considered illegal in most sane jurisdictions. What I’m showing is for educational purposes ONLY, and should NOT be attempted on any machines or networks that aren’t yours. There’s also the possibility of data loss should you follow anything in this post, so make sure to have backups of anything important, and only perform anything in an isolated and controlled environment. If you’re dumb enough to try any of this stuff on your critical systems and you lose data, or you decide to try it on a machine that isn’t yours and now you’re in federal prison, then don’t come crying to me saying that I told you to do something illegal. I warned you.

If you want to hack Linux machines legally, then check out VulnHub or Hack The Box for more machines like the one I’m demonstrating in this post.

Now that we’ve got the legal stuff out of the way, time for the actual post.

Backstory: Why This Post Even Exists

The backstory isn’t exactly relevant to the hacking itself, so feel free to skip this if you don’t care.

Recently, in my pen-testing class, I got assigned a group project, which usually I hate. This is because there’s generally a massive knowledge gap between me and the other group members, so this results in a huge imbalance of work. Regardless, our professor had assigned us a Linux machine that we were supposed to hack into. Our professor only told us that it was some sort of server, gave us a VM image, and no other details.

Long story short, while waiting for my group members to figure out what to do with it, I got bored over my Spring break and hacked into the VM myself. This happened well before they did anything with the VM, so now I’m writing this post as a tutorial for them, and educational/entertainment content for you. This post will show how I got to that point.

First Observation: Metasploitable 2?

When I first booted up the VM, I noticed that the boot screen looked awfully familiar:

It reminded me of Metasploitable 2, a purposely vulnerable Ubuntu machine we’ve been using in class that’s basically designed to demonstrate different exploits using Metasploit. As I later found out, while it wasn’t directly based off of Metasploitable 2, it used a similarly old version of Ubuntu.

First Steps: Scanning The Target

The very first thing I did was get the IP address and run an aggressive nmap scan on it:

Even though there wasn’t much running, it was running an ancient version of Apache, PHP, and SSH, with an equally ancient Linux kernel. Regardless, I still got excited because I knew it was going to get interesting.

About Apache

Since we now know it’s running a web server, let’s see what it’s hosting:

Oh look, a blog! While I did later find out that there were a few hints on it, the first thing that caught my attention was that Login button, so let’s click it and see what happens:

We’ve got ourselves a login screen that reveals a critical detail: The server is running LotusCMS, which I quickly found out was a notoriously vulnerable blogging platform.

Let’s see what else is running on this server by running nikto:

I made multiple observations, including multiple pages that ran phpinfo(), and much more interestingly, phpMyAdmin, which I initially assumed was responsible for managing the database for LotusCMS. Let’s navigate to /phpmyadmin and see what surprises we get:

Wow! That is an absolutely ancient version of phpMyAdmin. Since I got excited about the LotusCMS exploit, I didn’t spend much time with phpMyAdmin.

Getting a Foothold: Exploiting LotusCMS

Exploiting LotusCMS proved to be a bit more difficult than I initially thought, but regardless, it was still very easy. Since I had it right at my fingertips, I searched Metasploit for LotusCMS, and found the Holy Grail:

With an excellent rank and a disclosure date from forever ago, it seemed like the perfect exploit, so I went ahead and configured it:

And I tried to exploit it:

Which after a few attempts, failed. Unfortunately, even after a bit of trial and error, it didn’t work.

Plan B: DuckDuckGo To The Rescue

After my fail with Metasploit, I decided to give a quick search for LotusCMS on DuckDuckGo, and even after just simply typing “lotuscms” revealed this on GitHub:

Yeah it’s definitely not a great sign for security when you’re searching up a product online and the very first thing that comes up, even before the official SourceForge repository, is a exploit on GitHub for it. Regardless, I knew that this was probably my ticket, so I used Metasploit to create a reverse listener:

I then downloaded the script and configured it:

And after a few seconds:

Success! We’ve got ourselves a shell. You might notice that the path for the web server is /home/www/kioptrix3.com, which tells us that this VM was originally from kioptrix.com, a now defunct website owned by some gambling website in a language that I can’t speak. You can still view the original kioptrix.com website on the Wayback Machine. Regardless, I figured that our professor grabbed a vulnerable VM from somewhere for us to hack rather than making their own, and I’m not sure if/how many changes my professor made to it, but it’s still interesting to know the backstory.

Doing a Bit of Exploring

Now that we have access to a shell, let’s do a bit of exploration:

There’s kind of a lot going on here, mainly because I don’t feel like taking a bunch of screenshots, but as you can probably see, I find a file named salt.dat in data/config (Relative to /home/www/kioptrix3.com), and in data/users, I find a file named admin.dat, that contains some information on the admin user. We can save these for later as we can use this to crack the admin password.

We can also check the password files to see what access we have to them:

Unsurprisingly, they didn’t make /etc/shadow world-readable, nor are password hashes are stored in /etc/passwd, so let’s explore some potential privilege escalation methods.

The Fun Part: Exploring Privilege Escalation

Since this VM is running Linux kernel 2.6.24, there are plenty of potential privilege escalation vulnerability, including the notorious DirtyCOW exploit, allowing unprivileged users to write to read-only files like /etc/passwd. Even though I got excited again and used this method the first time, I found something that was much easier and didn’t require kernel-level exploits.

First, lets explore /home:

There isn’t much of interest in dreg, however, even though loneferret‘s bash history is empty, there are a couple of interesting files: CompanyPolicy.README, and checksec.sh. Let’s see what CompanyPolicy.README contains:

Boom, full sudo privileges to run ht, which is a hex editor. There are a few ways of exploiting this, but we’ll get to that later. For now, let’s change our focus to trying to get into loneferret.

Brute Forcing Our User’s SSH Login

As you might have recalled earlier, SSH was open on the VM, so let’s try using nmap’s ssh-bruteforce script, adding the users we found to a list, and using good old rockyou.txt as a password list:

After a bit of waiting, we’ve got ourselves a hit for loneferret:

Let’s try SSHing into loneferret, and see what happens:

Unfortunately, the SSH client included with Kali doesn’t like the ancient OpenSSH server included with our VM, and even after messing around, it still refused to connect. But don’t worry, I have a workaround.

First, install Docker with their convenience script (Or another method described in their documentation):

curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

Next, create a Ubuntu 14.04 container, since we can install an SSH client old enough to connect:

sudo docker run --rm -it ubuntu:14.04 bash

After it pulls the image and creates the container, your prompt should change to something like this:

root@<random string>:/#

From there, run the following command in the container to install openssh-client:

apt update && apt install -y openssh-client

After that, you can now use ssh loneferret@ip-address to connect to the VM:

Exploiting Sudo Permissions

Now that we’re logged in as loneferret, let’s see what sudo permissions we have by running sudo -l:

It appears that we only have access to ht, and have been explicitly denied access to su. So let’s open up /etc/sudoers to change that.

Before I continue, now is a good time to take a snapshot, because if you break sudo, then you’re basically screwed (Unless if you want to boot another OS and fix it), so please, take some sort of snapshot or backup before continuing.

After opening /etc/sudoers in ht, you’ll get a crazy looking screen like this:

This is because ht is designed to be a hex editor, and not a text editor. You can still view text files normally by switching modes, but you can’t edit them. Regardless, I’ll show you how to safely(ish) edit /etc/sudoers in ht in its hex view.

First, press F4 on your keyboard to switch to edit mode. You’ll probably notice that your arrow keys move around the cursor.

Next, press Tab on your keyboard. You will see the cursor switch over to the plaintext part.

Next, navigate to the part in the file where it starts with loneferret ALL=NOPASSWD:

Since there’s a lot going on with no line breaks, it might be difficult to find at first. My cursor in this screenshot is white and indicates where you need to be in the file.

Next, and this is an extremely important step to pay attention to, otherwise you’ll need to revert back to that aforementioned backup/snapshot, type over /usr/local/bin/ht with /bin/bash. Since there’s no way to delete characters, and ht only lets you replace characters, replace the extra ones with a space, right up until the red ??:

The text that you overwrote will appear in red. It should look something like my screenshot. If you think you messed up, press F10 to quit without saving, and open it up again.

To verify that you edited the file correctly, especially since sudo can be very picky about syntax, press F6 on your keyboard to bring up the mode selection:

Use your arrow keys to move to text, and press enter. The lines we edited will appear towards the bottom and are a bit hard to spot at first glance (Especially given the poor background/text colors), but they should look like this:

Press F6 again to bring back the mode screen, then select hex. If it looks right, press F2 to save, and then Press F10 to exit.

Next, run sudo -l to verify that your sudoers file syntax is correct:

If you get a prompt asking for your password and/or you get a syntax error, then it’s time to use that snapshot you took. If it looks like the above screenshot, then congrats! You’ve successfully edited /etc/sudoers using a hex editor without breaking it!

Now that we can run bash with full root permissions, let’s try that:

Success! Now we can navigate to /root and retrieve our congratulations message:

Congratulations! You can now say that you’ve hacked a Linux system by simply exploiting a web server (Using the term “simply” loosely).

But Wait! There’s More

Since you now have the entire VM in the palm of your hands, we can do a bit of exploring.

Maintaining Persistent Access

Any good hacker will want to have persistent access to the machine they just hacked, because what would happen if that security hole was closed? We can simply accomplish this by creating a new user, and in case you didn’t already discover, the admin group gets full sudo permissions:

Next, log out of root and loneferret, and try SSHing using your new user:

Success! Now you’ve got your own user.

Important Note

For whatever reason that I haven’t bothered to figure out, it seems like the VM will wipe out any newly created users after you shut it down. I’m not sure if this is a bug or what, but I decided to just simply give loneferret full sudo permissions.

Now that we can access all tools that require root, we can now safely edit /etc/sudoers with visudo, so open visudo. If you’re not root, then make sure to use sudo at the beginning:

EDITOR=/bin/nano visudo

Next, where we gave loneferret access to /bin/bash, comment out that line, and add the following line to give loneferret full sudo permissions:

Your file should look like mine. Since we’re using visudo to safely edit /etc/sudoers, you don’t have to worry about bad syntax breaking sudo since visudo verifies it. To verify that loneferret now has full sudo permissions, switch to loneferret with su loneferret (If you’re not already loneferret), and run sudo -l:

What About LotusCMS?

Even though we’re in the VM itself now, we can’t forget to hack the thing it’s actually hosting: LotusCMS. After exploring LotusCMS’s files, I managed to track down the function that generates the admin password, located in /home/www/kioptrix3.com/core/lib/User.php:

So what it does is it takes the passwords, adds the salt to the end of it, and hashes it with SHA1:

sha1(password.salt)

Thankfully Hashcat has a mode for this, so let’s first add add our password with its salt to a file, and try cracking it with rockyou.txt using best64.rule for our rules:

That was… extremely fast, even on my crappy lab VM. Regardless, now that we know that the username is admin and the password is Mast3r, let’s try logging in:

That’s… not supposed to happen. It appears someone bought the domain lotuscms.org, and after doing a bit of debugging with inspect element, they’re making update.lotuscms.org and news.lotuscms.org redirect to some sketchy ad domains that are being blocked by my DNS servers.

Thankfully, you can fix this by SSHing into the LotusCMS VM again, and adding the following lines to /etc/hosts (You need root permissions to edit it):

0.0.0.0    update.lotuscms.org
0.0.0.0    news.lotuscms.org

Now you just need to restart your browser (Or open a private session), and let’s try logging in again. It’ll take a little bit since it’ll try contacting those domains and eventually time out:

Success! Despite a few warnings from us blocking those domains, it works! We can now navigate the dashboard without worrying about getting redirected to some sketchy domains. Some pages like settings may take a bit to load because it’ll try contacting those domains again, but regardless, it all works.

Gallerific

When we were exploring the root of LotusCMS earlier, you might have noticed a folder named gallery. As it turns out, it’s yet another service that this server is hosting. Unfortunately, there doesn’t seem to be any Metasploit modules for it, but regardless, let’s check it out:

That doesn’t look right. Since it appears that kioptrix3.com is hardcoded in multiple places, it’s trying to connect to that domain, which doesn’t exist, but you can fix that by adding kioptrix3.com to your clients /etc/hosts file, replacing the IP address with the actual IP address of the LotusCMS box:

10.1.1.20     kioptrix3.com

That’s a little better now:

There’s no apparent login button, but we can figure out where the login page is by simply exploring the gallery folder:

Let’s navigate to http://kioptrix3.com/gallery/gadmin in our browser and see what happens:

The good news is that we’ve got ourselves a login page. The bad news is that the credentials for LotusCMS don’t work on it, so let’s try getting them.

Getting The Login

If you check gconfig.php in gallery, there’s hardcoded database credentials for a MySQL server:

Looks like it’s using the default root user and a password straight out of rockyou.txt, so let’s log in to phpMyAdmin using those credentials:

You can also use the mysql command, but what’s the fun of that when you have phpMyAdmin? Anyway, let’s explore the gallery database:

We’ve got ourselves a user table, so let’s check it out:

Sweet! The login is stored in plaintext, so we don’t need to worry about cracking it. Let’s try logging in with those credentials:

We’ve successfully logged in! Not only do we have full root access to our VM, but now we have full access to all of the services running on it.

phpMyAdmin?

As I was exploring the VM, I happened to notice something in /etc/phpmyadmin:

There was a file named htpasswd.setup containing a user named admin with no password, so I tried logging in with it:

Which turns out to be yet another valid login. Despite this, there didn’t appear to be anything interesting. Regardless, it still opens up another attack vector that I’m not going to go over, mainly because of a lack of time, and frankly this post is long enough as it is.

Conclusion

So that’s how I managed to hack into an old LotusCMS box, which was actually a lot of fun, and I plan on doing more of this in the future. I’m not sure if I’ll blog about similar stuff like this in the future, but I might, especially given my infrequency of posts (This was posted over a year after my last post, after all). This was also written on short notice, and even though it’s very long, clocking in at just shy of 3k words, I’m still very happy with the result of it. I promise I will try blogging more frequently, but I can’t guarantee anything.

In case you’re wondering, no, unfortunately I was not able to crack the root password, which doesn’t matter much anyway since we have full root access to the VM, and can easily change it.

The post Hacking an Old LotusCMS Box appeared first on Alex's Home Network.

In order for this to work, there are three main elements: Your desktop environment, Xvnc acting as a VNC server, and KasmVNC acting as a VNC client. Xvnc ties everything together by not only acting as a virtual display for Xorg, but also acting as a VNC server, which is then used by KasmVNC to display your desktop environment inside of your web browser. You can use noVNC instead of KasmVNC because it adheres to the VNC standard unlike KasmVNC (Allows you to use traditional VNC clients), but I prefer KasmVNC because it’s easier to setup, it’s better documented, and it seems to work better in my experience.

Prerequisites

• An up to date Debian 11 or Debian 12 host (I’ll be using Debian 12).
• KasmVNC recommends an up to date Chromium based web browser (All of the popular ones should work), or Firefox. Safari is unsupported due to it being incompatible with their authentication system.

Unfortunately, from what I can tell after doing some research, KasmVNC and noVNC don’t seem to have native support for audio, which seems to be due to a limitation of the VNC protocol. If you need to use audio, you’ll most likely need to stick with Webtop, setup a Kasm server (Same people that develop KasmVNC), or find a workaround.

Installing a Desktop Environment

The first step is to install a desktop environment of your choice. KasmVNC should work with any desktop environment or window manager, but it’s preconfigured for Cinnamon, Mate, LXDE, LXQT, KDE, Gnome, and XFCE out of the box. Other desktop environments may require some additional configuration.

I will be using XFCE throughout this post, so to install Xorg and a minimal XFCE installation, run the following command:

sudo apt install --no-install-recommends xfce4 xorg policykit-1 xfce4-power-manager xfce4-terminal

The package xfce4-terminal is not needed if you’re going to use a different terminal. You can also install the xfce4-goodies package to install many of the packages typically included with an XFCE installation, or look through what packages it includes to pick out the ones that you want.

After your desktop environment has finished installing, it’s time to move on to the VNC side of things.

Installing KasmVNC

First install. wget so that way you can download the package for KasmVNC:

sudo apt install wget

Next, navigate to the releases page on their GitHub (Found Here), and under Assets, copy the link to download the package appropriate for your Debian version and architecture, and use wget to download it (I would recommend saving it in /tmp so it get automatically deleted). The command shown below is what I ran since I’m running Debian 12 (Bookworm) on a 64bit system:

wget https://github.com/kasmtech/KasmVNC/releases/download/v1.2.0/kasmvncserver_bookworm_1.2.0_amd64.deb

If you’re running Debian 11, replace bookworm with bullseye. If your host has an ARM processor, replace amd64 with arm64.

Next, navigate to where you saved the package, and run the following command to install it:

sudo apt install ./kasmvncserver_*.deb

Next, run the following command to create the ssl-cert group and add yourself to it:

sudo addgroup $USER ssl-cert

If you get an error that looks something like this:

addgroup: addgroup with two arguments is an unspecified operation.

Run the following command instead:

sudo usermod -aG ssl-cert $USER

After running one of the above commands, log out and log back in again. Run the id command to verify that you’re apart of the ssl-cert group. For example, this is what it looks like with me:

alex@wp-blog:~$ id
uid=1000(alex) gid=1000(alex) groups=1000(alex),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev),109(ssl-cert)

After that, run the vncserver command, which will prompt you to select a desktop environment, and create a user. If you’re not using a desktop environment that KasmVNC is preconfigured to work with, you may need to select the option to manually edit xstartup. Consult your desktop environment’s documentation for more information.

After you have went through all of the prompts, you should see a message that looks something like this:

New 'wp-blog:1 (alex)' desktop is wp-blog:1

Users configured:
alex (can use keyboard and mouse)

Log file is /home/alex/.vnc/wp-blog:1.log

Starting applications specified in /home/alex/.vnc/xstartup

Paste this url in your browser:
https://127.0.1.1:8444

Type in https://host-ip-address:8444 into your web browser, and after bypassing the SSL certificate warnings and logging in, you should now be able to see your desktop environment:

Configuring Policykit

As you were playing around with your desktop environment, you might have noticed a problem:

As you can see, some of the buttons are grayed out and are unclickable. At least in the case of XFCE, this issue is due to the fact that Policykit isn’t configured out of the box, so we have to configure it ourselves.

First, create the directory to house the Policykit rules (Assuming it doesn’t already exist), and set the permissions accordingly:

sudo mkdir /etc/polkit-1/rules.d
sudo chmod 755 /etc/polkit-1/rules.d

Next, create a file named 85-reboot.rules inside of the /etc/polkit-1/rules.d directory, and add the following contents:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.reboot" &&
        subject.isInGroup("users")) {
        return polkit.Result.YES;
    }
});

Next, create another file named 89-power-off.rules in the same directory, and add the following contents:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.login1.power-off" &&
        subject.isInGroup("users")) {
        return polkit.Result.YES;
    }
});

After creating both files, set the permissions accordingly:

sudo chmod 644 /etc/polkit-1/rules.d/85-reboot.rules
sudo chmod 644 /etc/polkit-1/rules.d/89-power-off.rules

Next, open /usr/share/polkit-1/actions/org.freedesktop.login1.policy in a text editor and look for the below lines, then change <allow_any>auth_admin_keep</allow_any> to <allow_any>yes</allow_any>:

<action id="org.freedesktop.login1.reboot">
                <description gettext-domain="systemd">Reboot the system</descri>
                <message gettext-domain="systemd">Authentication is required to>
                <defaults>
                        <allow_any>yes</allow_any>
                        <allow_inactive>auth_admin_keep</allow_inactive>
                        <allow_active>yes</allow_active>
                </defaults>
                <annotate key="org.freedesktop.policykit.imply">org.freedesktop>
        </action>

Next, look for the below lines in that same file, and also change <allow_any>auth_admin_keep</allow_any> to <allow_any>yes</allow_any>:

<action id="org.freedesktop.login1.power-off">
                <description gettext-domain="systemd">Power off the system</des>
                <message gettext-domain="systemd">Authentication is required to>
                <defaults>
                        <allow_any>yes</allow_any>
                        <allow_inactive>auth_admin_keep</allow_inactive>
                        <allow_active>yes</allow_active>
                </defaults>
                <annotate key="org.freedesktop.policykit.imply">org.freedesktop>
        </action>

After rebooting and running the vncserver command again, you should now be able to shut down or reboot from your desktop environment. The process for configuring rules for stuff like suspending is basically identical. The only difference is that you’ll have to change (action.id == "org.freedesktop.login1.power-off" to the appropriate rule in the .rules file, and look for the appropriate rule in /usr/share/polkit-1/actions/org.freedesktop.login1.policy.

Systemd Service

As you might have noticed, everytime you reboot your host, you have to log in and run the vncserver command to start KasmVNC. This isn’t a big deal, but it’s a little annoying.

First, create a file under /etc/systemd/system and name it kasmvnc.service. After creating it, add the following contents, replacing yourusername with the user that you run KasmVNC as:

[Unit]
Description=KasmVNC Service
After=network.target

[Service]
Type=simple
User=yourusername
Group=ssl-cert
ExecStart=vncserver -fg
Restart=on-success
RestartSec=5

[Install]
WantedBy=default.target

To provide a quick explanation of what you’re looking at, ExecStart=vncserver -fg makes the vncserver command run in the foreground, which prevents the service from immediately stopping and killing KasmVNC. Logging out through your desktop environment will exit KasmVNC and also kill the service, so Restart=on-success and RestartSec=5 will automatically restart the service after 5 seconds. The User and Group options determine what user and group runs KasmVNC.

After creating the service, reload Systemd’s services into memory:

sudo systemctl daemon-reload

Then start and enable the KasmVNC service you just created:

sudo systemctl enable --now kasmvnc.service

After rebooting, you should now be able to access KasmVNC without logging in and running the vncserver command.

If you get an error message that looks like this (Happens on XFCE at least):

You’ll need to install the dbus-x11 package:

sudo apt install dbus-x11

After rebooting, you should now be able to access KasmVNC with no problems.

Optional: Reminder for Forgetful Folks

If you’re a more forgetful person like me, then you might forget that you have KasmVNC installed since there’s no indication on your host’s console that you have it installed. Thankfully, it’s easy to fix this problem.

Editing /etc/motd

The much simpler method is simply opening up /etc/motd in your favorite text editor, and changing the default message to whatever you choose. This message is displayed everytime a user logs in to the host. Here’s what mine looks like for example:

Linux wp-blog 6.1.0-16-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) x86_64

Hey Dumbass,

You forgot (again) that the desktop is only accessible through KasmVNC.
The URL is https://ip-address:8444
Last login: Fri Dec 22 16:20:11 2023 from 10.0.1.69
alex@wp-blog:~$ 

Despite this being a nice and simple solution, the only problem is that you’ll only see this message if you try to log in.

A More Visually Pleasing Method

Unlike the last method which will only show a text-based message after logging in, this method will show a message in the form of an image, and it doesn’t require a user to log in. There’s probably a more efficient method, but the method that I like using and I will be showing you is using Openbox to display an image of your choice.

The first step is to install Openbox along with the other packages that we’ll need:

sudo apt install --no-install-recommends openbox lightdm unclutter feh

Enable the LightDM service:

sudo systemctl enable lightdm

After rebooting your host, you should see LightDM come up and ask for your login. In the top right corner, click the page icon with a wrench, and make sure that Openbox is selected (As shown in the screenshot):

Enter your login information, and after clicking Log In, you should now see a black screen with a mouse cursor. Right click to access the Openbox menu, and if you’re not using SSH (Which I highly recommend that you do), locate your terminal under the Applications menu.

After accessing your terminal, open /etc/lightdm/lightdm.conf in a text editor of your choice. Locate the section that starts with [Seat:*], and locate the lines autologin-user and autologin-user-timeout towards the bottom. To provide a visual, you should see the following lines:

[Seat:*]
#Rest of output not shown
#autologin-guest=false
#autologin-user=
#autologin-user-timeout=0
#autologin-in-background=false
#Rest of output not shown

Uncomment the lines autologin-user and autologin-user-timeout, and replace yourusername with your name after autologin-user:

[Seat:*]
#Rest of output not shown
#autologin-guest=false
autologin-user=yourusername
autologin-user-timeout=0
#autologin-in-background=false
#Rest of output not shown

Notice how the lines autologin-user and autologin-user-timeout have been commented out. Since LightDM is automatically logging in to this user, you might want to create a separate user with little to no privileges. This is because someone with physical access to your host can access everything that your autologin user has access to. We’ll address this later by locking down Openbox.

Next, create the image with the message that you want displayed, and upload it to your host. If you need a little inspiration, here’s what I use on one of my VM’s:

Next, verify that your image displays correctly by setting it as the wallpaper:

feh --bg-scale /path/to/image

Since it’ll reset when you reboot your host, open /etc/xdg/openbox/autostart in a text editor, and add the following lines at the end:

feh --bg-scale /path/to/image & unclutter -display :0 -root -idle 0

The unclutter command will automatically hide the mouse cursor. After rebooting your host, you should see your image come up.

If your screen keeps blanking, install the x11-xserver-utils package and add the following lines instead:

feh --bg-scale /path/to/image & unclutter -display :0 -root -idle 0 & xset -display :0 -dpms s off

Locking Down Openbox

Since the right click menu along with all of the keyboard shortcuts still work, we’ll need to disable all of this to help secure our autologin user. Fortunately, it’s easy to lock Openbox down.

First, create a directory for Openbox inside of your home folder:

mkdir $HOME/.config/openbox/

Next, copy the default configuration file to the directory that you just created:

cp /etc/xdg/openbox/rc.xml $HOME/.config/openbox/rc.xml

Next, comment out or remove everything inside of <dock>, <keyboard>, <mouse>, <menu>, and <applications>. For your convenience, here’s an Openbox configuration file with everything removed for you that you should be able to use:

<?xml version="1.0" encoding="UTF-8"?>

<openbox_config xmlns="http://openbox.org/3.4/rc"
		xmlns:xi="http://www.w3.org/2001/XInclude">

<resistance>
  <strength>10</strength>
  <screen_edge_strength>20</screen_edge_strength>
</resistance>

<focus>
  <focusNew>yes</focusNew>
  <followMouse>no</followMouse>
  <focusLast>yes</focusLast>
  <underMouse>no</underMouse>
  <focusDelay>200</focusDelay>
  <raiseOnFocus>no</raiseOnFocus>
</focus>

<placement>
  <policy>Smart</policy>
  <center>yes</center>
  <monitor>Primary</monitor>
  <primaryMonitor>1</primaryMonitor>
</placement>

<theme>
  <name>Clearlooks</name>
  <titleLayout>NLIMC</titleLayout>
  <keepBorder>yes</keepBorder>
  <animateIconify>yes</animateIconify>
  <font place="ActiveWindow">
    <name>sans</name>
    <size>8</size>
    <weight>bold</weight>
    <slant>normal</slant>
  </font>
  <font place="InactiveWindow">
    <name>sans</name>
    <size>8</size>
    <weight>bold</weight>
    <slant>normal</slant>
  </font>
  <font place="MenuHeader">
    <name>sans</name>
    <size>9</size>
    <weight>normal</weight>
    <slant>normal</slant>
  </font>
  <font place="MenuItem">
    <name>sans</name>
    <size>9</size>
    <weight>normal</weight>
    <slant>normal</slant>
  </font>
  <font place="ActiveOnScreenDisplay">
    <name>sans</name>
    <size>9</size>
    <weight>bold</weight>
    <slant>normal</slant>
  </font>
  <font place="InactiveOnScreenDisplay">
    <name>sans</name>
    <size>9</size>
    <weight>bold</weight>
    <slant>normal</slant>
  </font>
</theme>

<desktops>
  <number>4</number>
  <firstdesk>1</firstdesk>
  <names>
    <name>desktop 1</name>
    <name>desktop 2</name>
  </names>
  <popupTime>875</popupTime>
</desktops>

<resize>
  <drawContents>yes</drawContents>
  <popupShow>Nonpixel</popupShow>
  <popupPosition>Center</popupPosition>
  <popupFixedPosition>
    <x>10</x>
    <y>10</y>
  </popupFixedPosition>
</resize>

<margins>
  <top>0</top>
  <bottom>0</bottom>
  <left>0</left>
  <right>0</right>
</margins>

</openbox_config>

Finally, save the file, and reboot your host. You should now no longer be able to access the right click menu or use any of the keyboard shortcuts.

Conclusion

After reading this post, you should now have a mostly working desktop environment within your web browser. Unfortunately, both KasmVNC and noVNC don’t seem to have any support for audio. Audio seems to be planned for KasmVNC, but it doesn’t appear to be for noVNC. There seems to be some workarounds, but I didn’t cover them in this post because it was getting long enough, and I felt like it was somewhat outside of the scope of it.

If you have an questions, comments, or complaints, feel free to leave a comment below. I’ll try my best to answer any questions that you might have.

References:

KasmVNC Documentation: https://www.kasmweb.com/kasmvnc/docs/1.0.0/index.html

XFCE Policykit Configuration: https://wiki.debian.org/Xfce#Suspend_and_backlight_issues

Setting a Wallpaper on Openbox: https://wiki.debian.org/Openbox#Wallpapers

Enabling Autologin for LightDM: https://wiki.debian.org/LightDM#Enable_autologin

The post Running a Linux Desktop Environment in Your Web Browser appeared first on Alex's Home Network.

Regardless of your choice of apps, these steps should be pretty similar. You can also choose to have some of these apps share the same VM or container. You could even run everything in Docker containers, but that’s outside of the scope of this post, and kinda defeats the purpose of it.

Prerequisites

The only things that you will need are a Proxmox host (Obviously), some basic knowledge of using Proxmox, and optionally but highly recommended a VPN that’s compatible with OpenVPN.

You should also plan on what services should share a VM or container, or if everything should be separate. I personally have Jackett and my *arr apps (Only Sonarr in my case) share a single container, and qBittorrent with my VPN share a single VM. Regardless of what you decide, the main issue that you need to worry about is ensuring that nothing uses the same port. Besides that, there shouldn’t be any concerns of conflicts.

qBittorrent with OpenVPN

You don’t need to run qBittorrent with a VPN, but chances are for the majority of the people reading this, I would highly recommend running one. Not only will running one improve the privacy and security of your setup, but you also won’t need to worry about your ISP sending you letters or cutting off your service.

Container Setup

If you plan on running qBittorrent inside of an LXC container, there’s a few steps that you have to take while creating it. The first step is if you’re storing your downloaded content on a separate machine, uncheck “Unprivileged container”. This will allow you to enable the needed features for transferring files over the network:

After creating the container, edit its configuration file:

nano /etc/pve/lxc/container-id.conf

Add the following lines to the configuration file:

lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir

Change the owner of /dev/net/tun to allow the container to access it:

chown 100000:100000 /dev/net/tun

This will make /dev/net/tun available to the container, thus allowing you to use OpenVPN.

Finally, start the container, and access its console.

Installing qBittorrent

After ensuring that the container starts and is up to date, ensure that the following packages are installed:

apt install curl gpg

By default, the container uses root as the default user and doesn’t have sudo configured, so this post will assume that you haven’t setup sudo. If you have setup sudo, use sudo on the appropriate commands.

Add the necessary repository to APT:

echo 'deb http://download.opensuse.org/repositories/home:/nikoneko:/test/Debian_12/ /' | tee /etc/apt/sources.list.d/home:nikoneko:test.list
curl -fsSL https://download.opensuse.org/repositories/home:nikoneko:test/Debian_12/Release.key | gpg --dearmor | tee /etc/apt/trusted.gpg.d/home_nikoneko_test.gpg > /dev/null
apt update

Run the following command to install qBittorrent without a GUI and with only the web interface:

apt install qbittorrent-nox

After it has successfully installed, run the following command to start the initial setup:

qbittorrent-nox

After accepting the agreement, you’ll be prompted with a username, password, and URL to login. Replace localhost with the appropriate IP address. Press Ctrl+C to exit once you’ve confirmed that qBittorrent works.

To run the qBittorrent service in the background, run the following command:

systemctl start qbittorrent-nox@root

You can also allow it to run at startup by running the following command:

systemctl enable qbittorrent-nox@root

If you get an error about a missing unit file, create a new one under /usr/lib/systemd/system/qbittorrent-nox@.service, then add the following contents:

[Unit]
Description=qBittorrent-nox service for user %I
Documentation=man:qbittorrent-nox(1)
Wants=network-online.target
After=local-fs.target network-online.target nss-lookup.target

[Service]
Type=simple
PrivateTmp=false
User=%i
ExecStart=qbittorrent-nox
TimeoutStopSec=1800

[Install]
WantedBy=multi-user.target

Run systemctl daemon-reload, and you should be able to run the aforementioned commands without issue.

As a quick side note, I noticed that the qBittorrent service can take a few minutes to stop, at least from my personal experience, so keep that in mind when rebooting the container.

Mounting Network Drives

If you plan on storing your downloaded content on a network drive, first ensure that the following check boxes are checked under Options then Features:

After enabling those features, install the needed packages:

apt install cifs-utils

Next, open /etc/fstab in a text editor, and add the following line (Add more if needed):

//ServerNameOrIP/ShareName /Path/Of/Choice cifs _netdev,username=YourUsername,password=YourPassword,iocharset=utf8 0 0

Run mount -a, then navigate to the directory that you chose to verify that it mounted correctly.

If you’re using a VM instead of a container, add the following line to your /etc/fstab (You also need cifs-utils installed)

//ServerNameOrIP/ShareName /Path/Of/Choice cifs _netdev,noauto,x-systemd.automount,username=YourUsername,password=YourPassword,iocharset=utf8,rw,uid=UIDofqBittorrentUser,gid=GIDofqBittorrentUser 0 0

You can get the UID and GID of your qBittorrent user by running id qBittorrentUser. Run mount -a, and navigate to the directory that you chose. Unlike the fstab for the container, after rebooting, the volume will only be mounted after something tries to access it, not at startup.

Log into qBittorrent, then under Options and Downloads, enter the path that you mounted your network drive to:

If you’re using something like Jellyfin or Plex, you’ll need to ensure that it has access to the directory that you chose.

OpenVPN

This step is optional, but for the reasons I stated above, I would highly recommend using one. There’s probably a better way of doing this, but this is a tried and true method that I’ve used enough times. If you don’t know what VPN to use, I personally have had a great experience with ProtonVPN, but there’s various options out there.

First, install the OpenVPN package:

apt install openvpn

Next, disable the default OpenVPN service. It’s enabled by default, and if you reboot your container, you’ll be staring at a black screen for minutes, then you’ll keep getting asked for a login (I found this out the hard way).

systemctl disable openvpn

Next, obtain the needed configuration files from your provider, and your OpenVPN username and password. If you happen to be using ProtonVPN, your OpenVPN username and password is located under Account, and the configuration files are located under Downloads.

Save your downloaded configuration file under /etc/openvpn/openvpn.conf, and create a text file under /etc/openvpn/login.txt with your OpenVPN username and password. It should look something like this:

ProvidedOpenVPNUsername
ProvidedOpenVPNPassword

Next, create a new Systemd unit file under /etc/systemd/system/openvpn-qbittorrent.service, and add the following content:

[Unit]
Description=OpenVPN Client for qBittorrent
After=network.target

[Service]
ExecStart=openvpn --config  /etc/openvpn/openvpn.conf --auth-user-pass /etc/openvpn/login.txt

[Install]
WantedBy=multi-user.target

Run systemctl daemon-reload, then run systemctl start openvpn-qbittorrent, and after ensuring that it’s running correctly, run systemctl enable openvpn-qbittorrent to allow it to run at startup.

Last but most importantly, login to qBittorrent then navigate to Options, Advanced, then select tun0 as the network interface. This will ensure that qBittorrent won’t try to fall back to a different interface in case your VPN goes down:

Now you should have a working qBittorrent install that’s protected by a VPN.

Jackett, Sonarr, and Others

Now that you have a working qBittorrent install with a VPN, it’s time to do something with it by installing some indexers. This is what will actually allow you to download content by using your qBittorrent setup.

You can either run these indexers inside of the same container as qBittorrent, or in their own container. I personally chose to run all of my indexers inside of their own separate container.

Jackett

After adding indexers to Jackett, its job is to simply look for the content that you tell it to by using something like Sonarr. After it has found the content that you’re looking for, it will relay that information to Sonarr (Or whatever *arr app you’re using) so it can start downloading it.

Jackett Install

Before you can install Jackett, you need to create a new user that has access to the sudo command. This is because Jackett will fail to install if you’re using the default root user, and even if you modify the script to allow it, you’ll get a banner saying that Jackett is being ran as root everytime you launch it.

First, install the sudo package:

apt install sudo

After installing the sudo package, create a new user, then add it to the sudo group:

useradd -mG sudo username

Set a password for the user:

passwd username

Now switch to the user, and try running any command with the sudo command to ensure that it’s setup correctly:

su username
sudo apt update

After verifying that sudo works correctly, ensure that wget has been installed:

sudo apt install wget

The Jackett developers provide this handy one line installation command:

cd /opt && f=Jackett.Binaries.LinuxAMDx64.tar.gz && release=$(wget -q https://github.com/Jackett/Jackett/releases/latest -O - | grep "title>Release" | cut -d " " -f 4) && sudo wget -Nc https://github.com/Jackett/Jackett/releases/download/$release/"$f" && sudo tar -xzf "$f" && sudo rm -f "$f" && cd Jackett* && sudo ./install_service_systemd.sh && systemctl status jackett.service && cd - && echo -e "\nVisit http://127.0.0.1:9117"

After Jackett has been successfully installed, visit Jackett by typing in your container’s IP address and the listed port.

Jackett Configuration

Configuring Jackett is very simple. All you need to do is add some indexers, and you’ll be all set. Here’s the indexers I personally use:

Feel free to scroll down and explore all of the other settings. We’ll get back to Jackett in a moment. At this point, I will be assuming that you will be using the default root user.

FlareSolverr Installation/Configuration

Since some indexers might use Cloudflare’s captcha, this may prevent Jackett from indexing them. Luckily someone made a very easy solution to this problem.

Since the recommended way to install FlareSolverr is to use Docker, you’ll need to setup Docker on your container. Before installing Docker, ensure that your container is a privileged container.

First, install Docker according to their documentation. I would recommend installing Docker using the APT repository as this makes it very easy to update. After you’ve verified that Docker is installed correctly, create a file named docker-compose.yml in a place that you would remember, then add the following contents:

version: "2.1"
services:
  flaresolverr:
    # DockerHub mirror flaresolverr/flaresolverr:latest
    image: ghcr.io/flaresolverr/flaresolverr:latest
    container_name: flaresolverr
    environment:
      - LOG_LEVEL=${LOG_LEVEL:-info}
      - LOG_HTML=${LOG_HTML:-false}
      - CAPTCHA_SOLVER=${CAPTCHA_SOLVER:-none}
      - TZ=Europe/London
    ports:
      - "${PORT:-8191}:8191"
    restart: unless-stopped

You should be able to keep all of the options at their defaults without any issues. You can run the container by running the following command:

docker compose up -d

If you’d rather not use Docker Compose, use the following Docker command instead:

docker run -d --name=flaresolverr -p 8191:8191 -e LOG_LEVEL=info --restart unless-stopped ghcr.io/flaresolverr/flaresolverr:latest

After the container has been created, enter yourcontainerip:8191 into your web browser, and you should see a message stating that FlareSolverr is ready. If you want to update FlareSolverr, run the following commands:

docker rm -v flaresolverr && docker rmi ghcr.io/flaresolverr/flaresolverr

Now use the docker run command or the docker compose command depending on what you chose.

Finally, configure Jackett to use FlareSolverr by scrolling down to the bottom of the page, and entering the URL to access FlareSolverr under FlareSolverr API URL:

Sonarr

Sonarr is used to tell Jackett what content to look for inside of your indexers, and it also instructs qBittorrent to start downloading it. Sonarr can even look for new releases to automatically download. All you need to do is add the shows that you want to watch to Sonarr, and it does the rest.

Sonarr Installation

I will only be showing the installation for Sonarr, but the installation process for similar *arr apps should be very similar.

First, add the Sonarr APT repository (Even though it says Buster, it works fine on Bullseye):

apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 2009837CBFFD68F45BC180471F4F90DE2A9B4BF8
echo "deb https://apt.sonarr.tv/debian buster main" | tee /etc/apt/sources.list.d/sonarr.list

Next, install the Sonarr package:

apt update && apt install sonarr

When prompted, just hit enter to keep the defaults. This will create a user named sonarr that will be responsible for well… running Sonarr.

If you want Sonarr to store your media on a network drive, you’ll need to install cifs-utils:

apt install cifs-utils

Next, get the UID and GID of the Sonarr user:

id sonarr

The /etc/fstab configuration is similar to the one that you used for qBittorrent:

# For containers
//ServerNameOrIP/ShareName /Path/Of/Choice cifs _netdev,username=YourUsername,password=YourPassword,iocharset=utf8,rw,uid=SonarrUserUID,gid=SonarrUserGID 0 0
# For VM's
//ServerNameOrIP/ShareName /Path/Of/Choice cifs _netdev,noauto,x-systemd.automount,username=YourUsername,password=YourPassword,iocharset=utf8,rw,uid=SonarrUserUID,gid=SonarrUserGID 0 0

Run mount -a, and browse to the path that you chose to ensure that the share was mounted correctly.

Sonarr Configuration

Open your container’s IP address with port 8989 in your web browser to access Sonarr. This is where all of the configuration of Sonarr will take place. First, you’ll want to tell Sonarr where to store all of your media, so click on Settings, then Media Management in the sidebar:

Next, scroll down to Root Folders, remove any unneeded ones by clicking the little X, and add your network share by clicking on Add Root Folder:

Next, configure Sonarr to use qBittorrent by clicking on Download Clients under Settings:

Under Download Clients, click the big button with the + icon:

Click qBittorrent under Torrents:

Finally, fill out the needed information according to your setup, then Click Test and Save:

Next, you’ll need to configure Sonarr to use your Jackett indexers by clicking on Indexers under Settings. At this point you’ll want to have the web interface for Jackett pulled up:

Next, click the large + button under Indexers:

Click Torznab under Torrents:

You should see a screen that looks something like this:

Next, navigate to Jackett, then click Copy Torznab Feed next to the indexer that you want to add:

Navigate back to Sonarr, then paste it under URL.

Next, copy the API key for Jackett. It’s displayed in the top right corner of Jackett’s page:

Paste your API key under API Key.

Finally, click on the Categories drop down menu, and select the categories as needed. This will vary from indexer to indexer. Configure all of the other settings as needed.

After you’ve configured everything, click Test and Save:

Finally, you should be able to click Series, and then add TV shows as needed. I could go over all of the options here, but I would recommend that you explore them yourself. I personally like using the interactive search instead of letting Sonarr look for new episodes automatically. Depending on how many indexers you have and other factors, it can take a long time:

Conclusion

After reading this post, you should now have a working *arr stack to automatically download your favorite TV shows. Unfortunately I can’t shows the installation process for Jellyfin since GPU passthrough doesn’t work correctly on my Proxmox host, and even though you technically don’t need it, I feel like it’s an important thing to have.

Feel free to leave any thoughts, suggestions, or complaints in the comments below. If you have any questions, I’ll try my best to answer them.

References

Proxmox’s official guide on running OpenVPN in LXC: https://pve.proxmox.com/wiki/OpenVPN_in_LXC

qBittorrent Installation: https://github.com/qbittorrent/qBittorrent/wiki/Running-qBittorrent-without-X-server-(WebUI-only,-systemd-service-set-up,-Ubuntu-15.04-or-newer

Jackett Installation: https://github.com/Jackett/Jackett

FlareSolverr Installation: https://github.com/FlareSolverr/FlareSolverr/

Sonarr Installation: https://sonarr.tv/#downloads-v3-linux

The post Installing an *arr Stack on Proxmox appeared first on Alex's Home Network.

Prerequisites

Before you start, you’ll need a working Grafana install (Instructions here if you don’t), and an Openweathermap API key. I would recommend using the Onecall API since it provides a good amount of information with a single API call (Although Grafana still makes multiple calls, more on that later).

Setting up The Raspberry Pi

Before creating your dashboard, you’ll want something to test it on. If you’re going to do the hardware part last, I recommend setting up a Debian VM with the same screen resolution as the display that you’re going to use. I’ll be going over hardware (Briefly) and software setup. If you’re not using the same hardware as me, then skip the hardware sections. If you only care about using the Openweathermap API with Grafana, then skip this entire section.

Hardware

The hardware I’m using is a Raspberry Pi 3B with an official Raspberry Pi touchscreen and a case that I happened to have laying around. The pictures below show the case that I’m using, and I believe that you can still purchase it on Amazon:

All I had to do to install the Pi was to put it in the case (It was kind of difficult because of the black foam pads), and screw in two screws. I also needed to connect the ribbon cable:

For whatever reason, the cover wasn’t fitting right, so I just clipped it in and rested it on the case. Luckily it still feels pretty secure:

And to my relief, my Pi (I manhandled it out of my old case) and my screen (It has been sitting for months) still worked. It’s impossible to find Pi’s for a reasonable price, so if I broke mine, then this blog post would be even more overdue.

Installing Raspberry Pi OS

Since the Pi will be doing nothing more than displaying a Grafana dashboard inside of a web browser, you don’t need anything fancy. You also don’t need to use Raspberry Pi OS specifically, but I recommend using it for the best compatibility. To install Raspberry Pi OS, download the Raspberry Pi Imager from here.

Once you’ve launched Raspberry Pi Imager, insert your SD card, and select the Choose OS button:

From the list, select Raspberry Pi OS (Other):

Since we don’t need a desktop or anything fancy preinstalled, select Raspberry Pi OS Lite (I recommend 64-bit for better software compatibility):

To save yourself some time, click the settings icon to preconfigure some settings. It will allow you to do stuff like enable SSH, set a hostname, and connect it to a WiFi network. I would recommend enabling SSH and setting a static IP later on so you can easily manage the Pi.

Once you click Save, select the Choose Storage button, select your SD card, then click write. Once it’s done, you should now have a bootable SD card for your Pi, and if you’ve preconfigured it, you shouldn’t need to do any additional setup for now.

After your Pi has successfully booted (And maybe asked a few questions depending on how you’ve preconfigured it), you should see a screen that looks something like this:

Installing Some Software

In order to display your Grafana dashboard, you’ll need some sort of desktop environment or window manager. I personally used Openbox with Lightdm, and I had it open Firefox automatically in kiosk mode. There’s probably a bunch of other ways of doing this (And might be more efficient), but I’ll show you my way.

First, you’ll want to install Openbox (Window Manager), Lightdm (Login Screen Thing), and XFCE Terminal (To manage the Pi directly if you need to):

sudo apt install openbox lightdm xfce4-terminal

Manually start Lightdm’s service:

sudo systemctl start lightdm

After about 5-10 seconds at most, you should see a login screen that looks something like this:

This is a more general tip, but if you’re stuck with a black screen, or you forgot to install a terminal emulator, you can switch your tty by using the following keyboard shortcut:

ctrl + alt + random function key

After a few attempts with random function keys, you should eventually be brought to a normal text-based terminal. Using F7 will bring you back to Openbox.

If you’re able to successfully login, you should see a screen that looks something like this (You might have a wallpaper):

To access the terminal, right click, and locate it in the applications menu. Configure Lightdm’s autologin by opening /etc/lightdm/lightgm.conf, and look for the following lines under [Seat:*]:

#autologin-user=
#autologin-user-timeout=

Uncomment both lines, and replace username with the user that you want to autologin with:

autologin-user=username
autologin-user-timeout=0

Restart Lightdm’s service:

sudo systemctl restart lightdm

And if you’ve followed these steps correctly, after a few seconds you should automatically be dropped into Openbox. If Lightdm’s service is not already enabled, enable it by running the following command:

sudo systemctl enable lightdm

After a quick reboot, Lightdm should automatically start then drop you into Openbox. If Lightdm still doesn’t run at startup, the following command fixed the issue for me (Credit):

sudo systemctl set-default graphical.target

The decade-old StackExchange thread also has a few other solutions if the above command didn’t fix the problem.

Installing Firefox

Now that you have an OS and a window manager, now you need something to actually display that Grafana dashboard. There’s probably better and more efficient ways, but I personally use Firefox since it works well enough. Most importantly, it has a built in kiosk mode that can be activated through the command line.

First, install Firefox:

sudo apt install firefox-esr

Launch Firefox through the right-click menu, and go into settings and disable everything that you can. By disabling everything, it helps to reduce writes to the SD card since Firefox won’t need to save anything, and it might even free up a bit of memory. A more adventurous user might be interested in Arkenfox, which will allow you to disable more stuff beyond the GUI. To run Firefox at startup, create the following file ~/.config/openbox/autostart with a text editor, and add the following line:

firefox --kiosk "dashboard-link"

If you haven’t created a dashboard yet, skip this step for now and come back to it later. If you did, then you should be able to reboot your Pi, and have it automatically display your Grafana dashboard.

Grafana

Before you can display your dashboard on your Pi, there’s a few steps that you need to do to enable anonymous access. You can sign in on your Pi, but I discovered during testing that it likes to sign me out every so often, so it’s important to enable anonymous access.

Anonymous Access

In order to enable anonymous access, open /etc/grafana/grafana.ini in a text editor, and locate the following lines:

#################################### Anonymous Auth ######################
[auth.anonymous]
# enable anonymous access
;enabled = false

# specify organization name that should be used for unauthenticated users
;org_name = Main Org.

# specify role for unauthenticated users
;org_role = Viewer

Remove the ;’s before the lines to uncomment them. For the organization specified in org_name, anonymous users will be able to view all dashboards created in it, so you might want to use a separate one for anonymous access, especially since the default organization specified is the default one. After uncommenting the enabled line, change false to true:

#################################### Anonymous Auth ######################
[auth.anonymous]
# enable anonymous access
enabled = true

# specify organization name that should be used for unauthenticated users
org_name = Main Org.

# specify role for unauthenticated users
org_role = Viewer

Restart your Grafana server, and try to access it logged out. It should now look similar to how it looked while logged in.

Installing and Configuring a JSON Plugin

As far as I’m aware, there doesn’t seem to be a plugin for the Openweathermap API, so we’ll have to do this the manual way. First navigate to the plugins screen:

By default, it might only be showing your installed plugins, so click All:

Next, type “json” into the search bar, and install the plugin that looks like this:

After you’ve installed the plugin, navigate to the Data Sources tab, click Add data source, then locate JSON API from the list of options:

Copy and paste the URL for the Openweathermap API, paste it in URL, and delete everything after the ?. The URL that you paste in should look something like this:

https://api.openweathermap.org/data/3.0/onecall?

Next, scroll down to Misc, and paste everything after the ? in Query string. The part of the URL that you paste should look something like this:

lat=notmylat&lon=notmylon&units=imperial&appid=notmyapikey

The configuration should look something like this:

Now click Save & Test to save your settings. If everything is working correctly, you should see a green check mark that says Success.

Before creating your dashboard, I would recommend messing around in the Explore screen. To actually query data, you’ll enter what data you want to get by using JSONPath. As an example, if you want to get the current temp and your API response looks something like this:

You’ll want your JSONPath to look something like this:

$.current.temp

The same concept applies if you want to get the content of the description field under the weather field:

$.current.weather.0.description

As another example, if you have an API response that looks something like this:

And you want to get all of the values of the precipitation field, your JSONPath would look something like this:

$.minutely.[*].precipitation

Here’s what the JSONPath for one of my panels looks like:

You probably get the idea, so experiment, and see what you discover and break.

Tips with Creating a Grafana Dashboard

Before you create your dashboard, I do have a few tips and tricks I’ve discovered, and they might even save you a few hours of troubleshooting. Here’s all of my tips in no particular order:

Correct Timestamps from Openweathermap API

Openweathermap returns all dates and times in Unix Epoch, but for whatever reason, having Type set to Auto will cause the time/date to display incorrectly. Set Type to Time to correct this:

Openweathermap API Decimal Weirdness

For whatever reason, the Openweathermap API will only display the precipitation probability as a decimal even though it seems to be a percentage. Every other percentage seems to be displayed as a regular number. This isn’t much of a problem, but it can create issues for panels like one of mine:

You might want to try and create a field override under the Overrides tab:

But this is what you’ll end up with instead:

Luckily this issue is easily solved by creating a simple transform rule:

This transform rule will add a new field that will represent the precipitation probability as a number like everything else. You can hide the old field by adding an override that looks something like this:

Automatic Grafana Dashboard Update and Kiosk Mode

To make your Grafana dashboard more useful, you’ll want it to automatically update. Plus, you probably don’t want to see the sidebar buttons and stuff like that. You could click the TV-looking icon in the top right corner and click the little dropdown next to the refresh button, but you probably don’t want to do that everytime your Pi reboots. A better solution is to use URL parameters. Simply set your settings to how you want them to be, then copy the URL. Your URL might look something like this:

http://10.0.1.183:3000/d/b7QDxVO4k/pi-dashboard?refresh=15m&kiosk

Notice the chances to the URL as you change your settings. You can also use playlists to cycle between multiple dashboards. But keep in mind that they refresh everytime they cycle, so it might be a problem for metered APIs.

Automatically Turn The Display On and Off

If you just simply want to disable screen blanking, this can be accomplished by running sudo raspi-config, and disable screen blanking under Display Options.

However, if your Pi display is located in a place like your room, chances are you’ll want to turn the display off at certain hours. Simply run sudo crontab -e, and add the following lines:

0 21 * * * sudo sh -c "echo 0 > /sys/class/backlight/10-0045/brightness"
0 7 * * * sudo sh -c "echo 40 > /sys/class/backlight/10-0045/brightness"

This will turn the display off at 9PM then turn it back on at 7AM. Use a website like crontab.guru to create your own crontab expression. Replace 40 with your desired brightness between 0 and 255. /sys/class/backlight/10-0045/brightness was the file that set the brightness of my display, but it might be different on your own set up.

Update 2/25/2023: For me at least, a recent update has seem to broken the xset commands for DPMS. Running them will result in nothing happening. From searching around online, other people seem to be complaining about the same problem. However, I haven’t found a properly working solution that will actually turn off the backlight and not just display a black screen. Your mileage may vary.

It’s also possible to make the display to turn off after a certain period of inactivity instead of at certain times. First, run sudo raspi-config, go to Display Options, then enable screen blanking. You’ll also want to ensure that the xscreensaver package isn’t installed. Next, install some packages that you might need (At least for me):

sudo apt install x11-xserver-utils libxcb-dpms0

Disable the default screen blanking:

xset s off

Then set how long you want your screen to stay on for before turning off:

xset dpms <time in seconds> <time in seconds> <time in seconds>

After you’ve confirmed that these settings work for you, add those two commands to your ~/.config/openbox/autostart file (These settings don’t seem to save on reboot). Here’s what mine looks like as an example:

xset s off
xset dpms 7200 7200 7200

You can also add su username -c "xset -display :0 dpms force off" to your crontab if you still want the screen to turn off at a certain time. Just keep in mind when scripting that these commands can only be run under the same user that your logged into your desktop environment as.

Addressing Rate Limiting Issues

From what I can tell, each individual panel will make its own API call even when they’re all using the same data source. Throw in a 15 minute or so refresh with enough panels, then that’s a lot of API calls! If you were like me and didn’t know this then added a bunch of panels, you might’ve gotten an email that looked like this:

Then soon discover that your Grafana dashboard was flooded with errors like this one:

Fortunately, the solution is pretty simple (Besides paying for your API calls). Simply combine multiple similar panels into one:

This should help reduce the amount of API calls that you use and eliminate those errors.

Conclusion

This is my first proper blog post, so hopefully you’ve enjoyed it and learned something new. This was a project that I’ve completed a couple months before I’ve gotten around to completing this post. As a result, this blog post a way overdue. If you have any problems, suggestions, or complaints, feel free to leave a comment. I have at least one other blog post in mind, so hopefully it isn’t as overdue as this one (No guarantees).

References

Various sections from Grafana’s documentation: https://grafana.com/docs/grafana/latest/

I’ve probably used my plugin’s docs at some point: https://grafana.github.io/grafana-json-datasource/

Since I’m bad at remembering things sometimes (Part of the reason why this blog post is so late), there’s probably some other resources that I’ve forgotten about.

The post Using Openweathermap with Grafana and Displaying it on a Raspberry Pi Touchscreen appeared first on Alex's Home Network.

This Post Has Been Replaced

Since this post is from 2022, and I frankly don’t really like it anymore, I have written an updated version of it. I’m keeping this post up for archival purposes and in case anyone happens to be curious. If you’re interested in following this post, please follow my newer one instead.

New Post: https://alexshomenetwork.com/fail2ban-nginx-cloudflare-debian-13/

Prerequisites

There really isn’t much you need, but make sure that you have the following:

• Full admin access to your WordPress site and full root access to your server. There’s a few steps that assume that you’ve already followed my previous posts. All steps assume that you’re running Debian, but most of them should be applicable to most popular distros.
• If you’re using Cloudflare, then some knowledge of how to use it is required. Also, make sure that the Proxy status is set to Proxied for your DNS records.

Locking Down /wp-admin and /wp-login.php (And other endpoints)

Despite it being pretty trivial and there being various methods of doing so, it seems to be pretty common for people to leave /wp-admin and /wp-login.php open to the internet. Not only does this give someone the ability to brute force your login, but it’s also another way for a potential zero-day to be exploited. I’ll be showing two ways of locking down /wp-admin and /wp-login.php to a specific IP address, but there’s many different methods. Regardless of what method you use, you’ll want to whitelist /wp-admin/admin-ajax.php since it’s used for WordPress’s AJAX API, which might cause some issues if it’s blocked.

There’s also a few different endpoints that you might want to block depending on what you’re using your website for.

The Cloudflare Way

This is the method that I personally use, and it’s also easier than the Nginx way if you’re using Cloudflare. Simply navigate to Cloudflare, click on your website, Security, WAF, and then finally click Create firewall rule. Your rule should look something like this:

You can also click the blue Edit expression link, copy and paste everything in the below code block, and replace the IP addresses with yours:

(http.request.uri contains "wp-admin" and ip.src ne 12.34.56.78 and not http.request.uri contains "/wp-admin/admin-ajax.php") or (http.request.uri contains "wp-login.php" and ip.src ne 12.34.56.78 and not http.request.uri contains "/wp-admin/admin-ajax.php")

Since Cloudflare firewall rules seem to take a bit to update, I would recommend waiting a minute after clicking Save before testing it. To test that your firewall rule works, navigate to /wp-admin and /wp-login.php. Once you’ve verified that you can still access it, do the same thing on a device with a different IP address. If everything is correct, you’ll see a screen that looks something like this:

The Nginx Way

Even though using Nginx is a little bit harder, you don’t need to be using Cloudflare for this step to apply to you. Locate your Nginx server block for your WordPress site (If you’ve followed my previous posts, then it should be in /etc/nginx/conf.d/wordpress.conf), then add the following lines above the very last } (Replace the IP addresses with yours):

  # wp-admin access
  location /wp-admin/admin-ajax.php {
      allow all;
  } 
  location /wp-admin {
      allow 12.34.56.78;
      deny all;
  }
  location = /wp-login.php {
      allow 12.34.56.78;
      deny all;
  }

Test your server block to ensure that it’s correct:

sudo nginx -t

And finally, restart Nginx:

sudo systemctl restart nginx

Like with the Cloudflare method, you’ll want to verify that /wp-admin and /wp-login.php is still accessible for only you, but blocked for everyone else. Try to navigate to /wp-admin and /wp-login.php, and you should still be able to access it. If you can still access it, try to navigate to /wp-admin and /wp-login.php with a device that has a different IP address. That device should be presented with a screen that looks like this:

Unable to Block /wp-login.php

If you were (un)lucky like me, then you’ll quickly notice that instead of your whitelisted IP address getting brought to a WordPress login screen, this will happen instead:

What appears to be happening is that Nginx is unable to execute the PHP code for whatever reason, so it’s just downloading it instead (Not sure if I described the issue correctly, please let me know in the comments if I was wrong).

The first thing that I tried was to remove the = sign since I noticed that removing it gave me different results when troubleshooting a different problem:

location /wp-login.php {
      allow 12.34.56.78;
      deny all;
  }

The good thing was that my login screen was working again, but the bad thing was that it wasn’t blocking anything.

I also gave up on trying to navigate Nginx’s documentation, but after searching online and trying many different things, I found this random article that actually worked. Armed with the knowledge from that random article, I looked for the following code in my server block:

 }
  location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    include snippets/fastcgi-php.conf;

    # Add headers to serve security related headers
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header X-Frame-Options "SAMEORIGIN";
  }

And made it look like this:

 }
  location ~ \.php$ {
    location ~ \wp-login.php$ {
        allow 12.34.56.78;
        deny all;
        fastcgi_pass unix:/run/php/php7.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        include snippets/fastcgi-php.conf;
    }
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    include snippets/fastcgi-php.conf;

    # Add headers to serve security related headers
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header X-Frame-Options "SAMEORIGIN";
  }

And to my surprise and relief, that actually worked. I don’t know how it works, so please don’t ask me to explain it. In the unlikely chance that you came here from a search engine looking to solve the same seemingly strange and obscure problem and I helped you, then you’re welcome internet stranger ;). If I didn’t, well I guess good luck on your journey.

Blocking xmlrpc.php

xmlrpc.php is used for an old API used to interact with WordPress. Since many API’s and features have taken its place and it’s commonly used for exploits, it’s best to disable it. You can either use a plugin, or firewall it off.

Cloudflare

To block this endpoint using Cloudflare, create a new firewall rule that looks something like this:

Like earlier, you’ll want to wait a minute to let the firewall rule update after clicking Save. After you’ve waited, try to navigate to /xmlrpc.php, and you should see an Access Denied screen like I showed you earlier.

Nginx

Like with blocking /wp-admin and /wp-login.php, all you need to do is locate your Nginx server block, and add the following lines:

# Block xmlrpc.php
  location = /xmlrpc.php {
      deny all;
  }

Test the server block:

sudo nginx -t

Then restart Nginx:

sudo systemctl restart nginx

Try to navigate to /xmlrpc.php, and you should get a 403 Forbidden screen like I showed you earlier.

Other Endpoints to Block

There’s a few other endpoints that I would recommend blocking. However, blocking certain ones might cause WordPress to break or not work properly. I’ll tell you what ones might cause WordPress to break by blocking them.

• /feed: This is a list of all of your posts in RSS format. It’s useful if you’re making a blog because users can easily add it to an RSS feed reader. It also reveals some information about your website, so if you don’t need it, then disable it.
• /wp-json: This appears to be some sort of WordPress JSON API. From what I can tell by looking at logs, it can reveal quite a bit of information about your website. Since there’s legitimate uses for it, I whitelist it based on IP address like with /wp-admin and /wp-login.php. However, even though I haven’t had any problems, it doesn’t mean that doing what I did won’t cause problems for you. Experiment with firewall rules before doing this on a production website and come to your own conclusions.

Besides blocking endpoints, you should also disable features that you don’t need, like comments for example. Usually you’ll be able to find a plugin that disables what you don’t need.

Correcting IP Addresses in Logs when Behind Cloudflare

If you’re using Cloudflare, you’ve probably discovered that the source IP addresses in your Nginx logs are Cloudflare’s IP address, not your visitors IP address. This can be a problem when running security measures on your server like Fail2ban since they won’t be able to get the actual IP address. Luckily, this is an easy problem to fix.

Open /etc/nginx/nginx.conf in a text editor, and add the following lines below line 37. This will create a new log file called wordpress.log, which will be identical to the default access.log, but it will include your visitors actual IP address:

log_format  wordpress  '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for" "$http_cf_connecting_ip"';
    access_log /var/log/nginx/wordpress.log wordpress;

Next, add a new line under line 66, and paste the following lines below. These are the lines that will get the actual IP address from Cloudflare (By the time you’re reading this, Cloudflare might have changed their IP address slightly, so check here):

# Get actual IP address from Cloudflare
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 104.16.0.0/12;
    set_real_ip_from 104.24.0.0/14;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 131.0.72.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    set_real_ip_from 2400:cb00::/32;
    set_real_ip_from 2606:4700::/32;
    set_real_ip_from 2803:f800::/32;
    set_real_ip_from 2405:b500::/32;
    set_real_ip_from 2405:8100::/32;
    set_real_ip_from 2c0f:f248::/32;
    set_real_ip_from 2a06:98c0::/29;
    set_real_ip_from 2c0f:f248::/32;
    real_ip_header X-Forwarded-For;

When you’re done, make sure to test the configuration file and restart Nginx. After that, you should start seeing your visitors IP address in wordpress.log.

Sucuri Security

Sucuri Security is a WordPress security plugin that can do stuff like audit logins, scan your website for malicious code, and many other things. I’ll be showing you how to configure some of the features. I recommend that you look through all of the settings yourself and configure everything to your specific needs.

Enable The WordPress Integrity Diff Utility

This feature will show the differences between WordPress files stored on your web server and ones provided by WordPress. After you install the plugin, select Sucuri Security, then Settings:

Select the Scanner tab:

And finally, scroll down to WordPress Integrity Diff Utility, and click Enable:

Apply Hardening Options

There’s a few options under here that will make your WordPress site a little bit more secure by doing stuff like removing unnecessary files. Assuming that you’re still at the same screen as the previous step, click the Hardening tab:

Then under hardening options, select the options that you see fit (I still want the theme and plugin editor):

If you want to change how often the secret keys are updated (Determines how often you’ll need to log in again), select the Post-Hack tab:

Then from the dropdown, choose an option that you see fit:

Enable Email Alerts

To enable email alerts, select the Alerts tab:

Enter an email address, then click submit (Remove email@example.com first):

Then finally, scroll through all of the options on that page and configure them as you see fit.

Fail2ban

Fail2ban is a neat little program that runs on your server that will check your logs, and if a certain IP address keeps matching a specific configured pattern within a certain amount of time, then it will block it. This only scratches the surface of what it can do. I’ll be showing you how to use Fail2ban to block IP addresses that are causing too many 4xx errors. There’s many automated scripts scanning websites on the internet, and since they’re trying to probe your website for vulnerabilities, naturally they’ll cause a lot of 4xx and other similar errors.

Installation

First, install Fail2ban, and select yes on all of the prompts:

sudo apt install fail2ban iptables iptables-persistent

Start Fail2ban:

sudo systemctl start fail2ban

And verify it’s running by using one of the two commands:

sudo systemctl status fail2ban

Or:

sudo fail2ban-client status

Once you’ve verified that Fail2ban is running correctly, allow it to run at startup:

sudo systemctl enable fail2ban

After you install Fail2ban, open /etc/fail2ban/fail2ban.conf in a text editor, and look for line 69 (Nice). Chances are you won’t want it to wipe the database after a single day, so change it to something longer like 99 years (Or shorter if you want it to wipe it at some point):

dbpurgeage = 99y

Save the file, then restart Fail2ban:

sudo systemctl restart fail2ban

Jail Configuration

By default, Fail2ban doesn’t have a filter for matching Nginx 4xx errors, so we’ll have to create one ourselves. Create a new file in /etc/fail2ban/filter.d/, and name it nginx-4xx.conf, then add the following lines (Regex I used, I slightly modified it):

[Definition]
failregex = ^<HOST>.*"(GET|POST).*" (401|403|404|444) .*$
ignoreregex = 

Next, open /etc/fail2ban/jail.conf in a text editor, and go to line 47. Uncomment bantime.rndtime, and add a value that you see fit:

# "bantime.rndtime" is the max number of seconds using for mixing with random time 
# to prevent "clever" botnets calculate exact time IP can be unbanned again:
bantime.rndtime = 24h

Paste the following code block starting at line 274. Change the highlighted values as you see fit, and also experiment with these settings first so you don’t ban legitimate users. If you you didn’t follow my steps for correcting IP addresses when behind Cloudflare, logpath should be /var/log/nginx/access.log:

[nginx-4xx]
enabled = true
port = http,https
logpath = /var/log/nginx/wordpress.log
maxretry = 5
findtime = 10m
bantime = 30m
action = iptables-allports

After you’ve saved the file and restarted Fail2ban, test it out. It might not seem like that it’s working at first since Fail2ban checks the log every few seconds (At least from what I can tell, not sure how often it actually gets checked). If you’re using Cloudflare, skip to the Cloudflare section since there’s additional steps that you need to do.

After you’ve verified that your IP was banned, unban it:

sudo fail2ban-client unban 12.34.56.78

And so you don’t accidentally ban your own IP like I’ve down multiple times, look for line 92 in /etc/fail2ban/jail.conf, uncomment it, and add your IP address:

ignoreip = 127.0.0.1/8 ::1 12.34.56.78

Cloudflare

If you tried to have Fail2ban ban your IP address, you’ll probably notice that your IP address wasn’t banned (Or in my case, IPv6 IP’s weren’t getting banned, but IPv4 IP’s were) despite sudo iptables -L or sudo ip6tables -L showing your IP address getting blocked. Luckily the solution is easy.

First, log into your Cloudflare dashboard, click the person icon in the top right corner, then click My Profile:

Select API Tokens from the sidebar:

Scroll down to API Keys, then click the View button by Global API Key:

After you’ve entered your password, copy this API key and save it somewhere secure. You’ll need it later:

Go back to your server, open /etc/fail2ban/action.d/cloudflare.conf, and scroll down to line 81. You’ll paste your API key next to cftoken, and enter the email address associated with your Cloudflare account next to cfuser. It should look something like the example below:

cftoken = 4655434b594f554e49434b554b4e4f5757484f55415245

cfuser = email@example.com

Open up jail.conf again, scroll down to where you’ve added the jail, and add cloudflare to the action line:

action = iptables-allports cloudflare

Before testing, just be aware that banning an IP through Cloudflare might take a little bit. This is because not only do you have to wait for Fail2ban to check your Nginx logs, but you also have to wait for Cloudflare to ban the IP as well, which seem to take at least 10 seconds.

Once your IP address has been banned, you can view the ban in the WAF settings under the Tools tab and IP Access Rules, and it should look something like this:

You can unban your IP by either clicking the X button, or use the fail2ban-client command I showed you earlier. Don’t forget to add your IP address under ignoreip in jail.conf so you don’t ban yourself by accident.

Making the Fail2ban Service Apart of the Nginx Service

If the Fail2ban service happens to crash, then you’ll loose the benefits of Fail2ban. However, if you wanted to, you can make it so if Fail2ban crashes, then it takes Nginx down with it. This also means that your website will be down until Fail2ban and Nginx is restarted, so only do this if you don’t mind potentially loosing uptime.

All you need to do is edit /lib/systemd/system/nginx.service, and add the highlighted line:

[Unit]
Description=A high performance web server and a reverse proxy server
Documentation=man:nginx(8)
BindsTo=fail2ban.service
After=network.target nss-lookup.target

Run the following command to make systemd pick up the changes you made:

sudo systemctl daemon-reload

Then to test this, kill Fail2ban:

sudo pkill fail2ban

Check the status of Fail2ban to ensure that it’s not running:

sudo systemctl status fail2ban

Then check to see if Nginx is also stopped:

sudo systemctl status fail2ban

Both services should be stopped, and you should be able to restart both services.

Cloudflare Settings

If you’re using Cloudflare, there’s some settings that you might want to look at or change. I’ll be showing what settings I personally use on both of my websites.

SSL/TLS Settings

To access these settings, simply click the SSL/TLS button after clicking your website when you log in:

Under Overview, there really isn’t a whole lot to change. I recommend selecting Full (Strict) for the SSL/TLS mode. If you can’t choose Full (Strict), you can also enable the SSL/TLS Recommender if you want Cloudflare to check if your website can use a more secure SSL/TLS mode.

Next, select Edge Certificates in the sidebar:

I have all of the options under here enabled, and I keep the Minimum TLS Version at the default. I also have HSTS enabled, but make sure to read the warning first before enabling it.

Security Settings

Accessing these settings as just as easy as accessing the SSL/TLS settings. All you need to do is just click the Security then WAF button:

Create a rate limiting rule to help mitigate against DDoS attacks. If you’re using a crappy server like me, then this is especially important. Simply click on the Rate limiting rules tab, then Create rule:

If you want it to match everything, then set it to if URI path contains /. Then for the rest of the settings, choose them as you see fit. I originally had it set to 100 requests within 10 seconds, but I had problems with it being too strict.

After you’ve configured rate limiting, select Settings in the sidebar:

I have everything turned on here. I have Security Level set to High, and I have Challenge Passage set to 1 day. The default security level isn’t strict enough, and if a visitor had completed a Cloudflare challenge, then they won’t have to do it again for 1 day.

Caching Settings

To access these settings, simply click Caching in the sidebar, then Configuration:

I only changed three settings in this menu. I have both Always Online and Crawler hints enabled, and I have Browser Cache TTL set to 1 month. Always Online is an especially neat feature because if your server goes down, then it will display a copy from the Wayback Machine instead. If you’re not changing stuff all that often on your website, then a longer browser cache TTL can help speed up your website and reduce bandwidth for repeat visitors.

Click Tiered Cache in the sidebar, and then enable Argo Tiered Cache. According to Cloudflare, this does some fancy magic routing to help improve performance and reduce bandwidth on your server.

Page Rules

Since some of Cloudflare’s features like caching can cause issues on /wp-admin, it’s best to disable them. This is easily possible thanks to Page Rules. From the sidebar, select Rules:

Click Create Page Rule to create a new rule:

Your page rule should look something like this, and replace example.com with your domain name:

After clicking Save Page Rule, this will disable Cloudflare’s features just on /wp-admin while leaving them enabled for everywhere else on your website.

Conclusion

I hope you enjoyed reading this post and this series in general, and maybe learned something new in the process. I definitely learned a lot about writing blog posts, which is why I decided to include a dedicated heading section. If you’ve read through all of my posts in their entirety, I bet that there’s probably some minor differences that I haven’t even noticed. If you’re getting tired of this series, don’t worry, since I have plans to write actually interesting stuff. Hell even I’m getting tired of writing posts for a series that people probably don’t want to read, so I’m glad that I stuck to writing only four parts.

Like usual, if you have a suggestion, problem, or complaint, then leave a comment, and I’ll try my best to address it.

References

A lot of my information is from looking at configuration files since I’ve forgotten how I did some stuff and what tutorials I followed.

These random tutorials did a better job of telling me how to block paths in Nginx than Nginx’s own documentation: https://www.linuxshelltips.com/block-access-wp-admin-and-wp-login/, https://www.linuxshelltips.com/block-xml-rpc-in-wordpress/

Using Fail2ban with Cloudflare: https://gridpane.com/kb/using-fail2ban-with-cloudflare/

The post Using Cloudflare and Fail2ban with WordPress – Building a WordPress Blog Part 4 appeared first on Alex's Home Network.

Comments

It may seem trivial, but this was actually pretty difficult for me when building this blog. I ran into various roadblocks like fighting off spam bots, or if I should require users to create an account. It didn’t help that by default, WordPress had basically no customization options for the comment box. After trying out many different WordPress plugins and lots of experimenting, but in the end, I settled on allowing users to comment anonymously, and a WordPress plugin for the comment box so I get the features I want.

wpDiscuz

That WordPress plugin I decided to use was wpDiscuz. What I like about this plugin is that it has lots of customization features, and most importantly, it has support for reCAPTCHA and email notifications (Although they didn’t seem to work in testing). There’s a few minor issues that I have with it like the formatting in the comment box looking different than what is displayed after you click “Post Comment”, and there’s some weird UX issues (Users don’t have the ability to delete comments, which is something I wanted), but overall it seems to get the job done just fine.

Details on wordpress.org

Akismet Anti-Spam

As it’s name implies, this plugin is a simple anti-spam plugin already included with every WordPress installation. All you need to do is create an Akismet account, enter your API key, then you’re basically all set. There’s a few simple options, but the defaults will be just fine for most people.

Details on wordpress.org

Email Notifications and Newsletter

This was another seemingly trivial thing that took a lot of experimenting a deciding (More specifically, newsletters). In the end, I decided to do everything through WordPress, mainly because it’s more convenient, and I can more easily switch email providers if I find a better one.

WP Mail SMTP

It might not have a very catchy name, but as its name also implies, this is a WordPress plugin for sending emails. By default, WordPress will use PHP to send emails, however, it’s not nearly as reliable as using a service like Sendinblue (What I’m currently using, no affiliate plug this time), and also most hosting providers block SMTP port 25. This will result in your emails having a much greater chance of not being delivered or going to spam. They do have a pro version with more features and customization, but the free version is good enough.

Details on wordpress.org

FluentCRM and Fluent Forms

After trying out various plugins and what Sendinblue has to offer, I decided to FluentCRM with Fluent Forms. Like every WordPress plugin, they beg you to pay for it, but luckily the free version has a decent amount of features. The main features that I wanted were mandating that users click on a link in a confirmation email to be subscribed, and also reCAPTCHA support. There was a surprising number of plugins that either lacked at least one of these features, or had the features I wanted behind a paywall, so it was relieving seeing that these plugins had those features for free.

FluentCRM:

Details on wordpress.org

Fluent Forms:

Details on wordpress.org

Optimization and Caching

If you want your website to run well, you’ll want at least some caching. Combined with Cloudflare, this can help your website load faster, which is especially important for users with poor internet, or are physically located far away from your server. I’ll be going over how to setup your WordPress install behind Cloudflare and what settings I chose for the WordPress plugins I’m about to list in a future post, so you can look forward to that and subscribe to my newsletter to get a notification right in your inbox.

Before installing any of these plugins, make sure that you get everything set up first. Otherwise, you’ll end up like me trying to figure out why changes aren’t behaving properly or saving just to find out that it was a caching plugin.

WP Fastest Cache

Like many WordPress plugins, it has a descriptive yet not so catchy name. But as its name implies, this is a plugin for caching. There’s a decent amount of features, but like every WordPress plugin, if you want more advanced features including statistics on your caching and stuff, you’ll have to fork up some cash.

Details on wordpress.org

Smush

Unlike most WordPress plugins, this one has a both catchy and somewhat descriptive name. This is a WordPress plugin for optimizing the images on your website. Not only does this plugin compress all of the images on your website without sacrificing quality, but it also includes features like lazy load. If you don’t know, lazy load is a neat thing that won’t display an image on your website until a user scrolls to it. This can save bandwidth by not pointlessly displaying images.

Details on wordpress.org

OMGF (Optimize My Google Fonts)

If you use Google Fonts on your website, then this is the plugin for you. This is a WordPress plugin that will download Google Fonts locally to your server. This will both improve privacy and performance for your visitors. Unlike a lot of WordPress plugins, the majority of features are free, and it doesn’t beg you to pay.

Details on wordpress.org

Presto Player

By default, WordPress doesn’t seem to handle videos very well. What seems to happen is that WordPress will use whatever video player your web browser has built in, and it’ll also load the entire video by default. This uses a lot of bandwidth and slows down your website for visitors, especially on a website like mostepicwebsite.com. With Presto Player, it lazy loads videos, and it will buffer them like how YouTube works instead of serving the entire video file. It also gives you the ability to customize the video player (More advanced customizations are paywalled), and use Google Analytics (Also paywalled, I guess they really want you to upgrade).

Details on wordpress.org

Forms

You probably already know what a form does and why you would want one, so without wasting anymore time, I’ll just jump right into my recommendation.

Forminator

You probably already guessed what this plugin does from its catchy, descriptive, and distinctive name, but this is a plugin for creating forms and stuff like that. This plugin is probably made redundant by Fluent Forms, but I don’t feel like comparing the features, so it’s staying. I picked this plugin not only because it has a lot of features, but the free version is also really good, and there’s only a handful of features that are paywalled. It also doesn’t feel pushy about paying for the premium version, which is something that I can’t say about the majority of WordPress plugins.

Details on wordpress.org

SEO

Since WordPress by default doesn’t offer many options in terms of SEO, you’ll probably want to install an SEO WordPress plugin to help with that. This way you can ensure that your website shows up in Google search properly and you actually get visitors.

Yoast SEO

I didn’t look too much into SEO WordPress plugins if I’m being honest, but I chose Yoast SEO mainly because it was recommended by a lot of people, and the free version had a good amount of features (Although they do like to beg you to upgrade). They also have a lot of helpful tutorials in articles that you can access simply by clicking the question mark icon.

Details on wordpress.org

Security and Backups

The last thing that you want when running a website is to have it get hacked, or loose all of your data because someone decided to use RAID 0. No matter how you lost your data this time, luckily WordPress plugin developers have thought of some solutions. Depending on your setup, there might be additional plugins that you need to install, but I’ll be covering security in my next post.

Sucuri Security

This is a security plugin that has various features, like audit logging, email alerts, website scanning, and more. This plugin also gives you tips on how you can improve the security of your website. Another thing that’s nice about this plugin is that it doesn’t seem to beg you for money.

Details on wordpress.org

UpdraftPlus

I personally use UpdraftPlus for backing up both of my websites. Even though it loves to beg you to buy the premium version, the free version has a decent amount of features, and it works well enough. I even used it to migrate mostepicwebsite.com and this blog from my testing environment (Although I did a backup and restore instead of using the migrate feature). There’s many different locations that you can backup to (Although almost half of them are paywalled).

Details on wordpress.org

The Little Things

There’s many fancy WordPress plugins out there, but there’s also many simple and very useful plugins that arguably should be features built into WordPress. For the most part, these plugins also have a very good free version and don’t beg you for money every 5 seconds.

Easy Table of Contents

As its simple name implies, this is a simple WordPress plugin for generation a table of contents on any post, page, or whatever you want. The vast majority of the features are free with very few of them being paywalled. Overall, it does exactly as it advertises, so no complaints. This is something that I wish was included with WordPress by default.

Details on wordpress.org

Remove Footer Credit

Another feature that isn’t included with WordPress but should be is the ability to disable footer credit. Luckily this very simple WordPress plugin solves that issue for you, and all it takes is a bit of skill with inspect element.

Details on wordpress.org

Velvet Blues Update URLs

If you’re migrating a WordPress website from one domain to another, then this another very simple but useful WordPress plugin. I’ve used this when migrating mostepicwebsite.com and this blog from my testing environment to my cloud server. This plugin allowed me to easily update all of the URLs on my websites so everything worked perfectly. Unfortunately it doesn’t seem to be maintained anymore, but since this plugin is so simple, it shouldn’t be prone to breakage or security issues.

Details on wordpress.org

Add From Server

If you’re using Cloudflare, then you probably know that Cloudflare limits the file size of your uploads. Luckily you can work around this by using FTP or something like that and upload the file directly to your server. Unfortunately you might discover that the file doesn’t appear in your media library despite it being in the correct directory and format. This simple WordPress plugin will come to the rescue by allowing you to select the file and manually add it to your media library. Like some other plugins here, unfortunately it’s not maintained anymore as far as I can tell. But because of it’s simplicity, you shouldn’t need to worry about any issues.

Details on wordpress.org

WP Dark Mode

Who doesn’t like having a dark mode on their website, especially on a website that looks like mine? This WordPress plugin allows your visitors to toggle between light and dark mode with a flip of a switch. They’re pretty pushy about paying for the premium version, but the free version works well enough, and I also can’t find a better free replacement.

Details on wordpress.org

Media Cleaner

A very useful WordPress plugin that helped me migrate mostepicwebsite.com from my testing environment was Media Cleaner. Somehow I ended up with a bunch of duplicates, but luckily this WordPress plugin made it very easy to remove all of them. Unlike a lot of WordPress plugins, it also doesn’t seem very pushy about its premium version.

Details on wordpress.org

I don’t have anything interesting for the conclusion for this post, but I hope that you enjoyed reading it and maybe was helpful. If you have any suggestions, comments, or complaints, then feel free to leave a comment. Also, stay tuned for part 4 (The final post in this series), where I’ll talk about using WordPress with Cloudflare and Fail2ban along with some other optimization and security tips.

Part 4: Coming Soon

The post My Top Picks for WordPress Plugins (Comments, Security, Email) – Building a WordPress Blog Part 3 appeared first on Alex's Home Network.

I have written an updated and much better version of this guide. I’m primarily keeping this post up for archival purposes, and if anyone wants to reference it for whatever reason. If you’re looking to follow this guide, follow the one I linked below instead.

New guide: https://alexshomenetwork.com/installing-wordpress-on-debian-13/

Old Post

If you’ve read my previous post and followed along, you should have a working LEMP stack. You’re probably thinking to yourself, now what? Well, today I’ll be showing you what I did with mine, which is installing WordPress. WordPress is an extremely popular CMS (Content Management System) that many of your favorite websites are based off of. Hell, even this arguably kinda crappy blog uses WordPress. A CMS allows someone to easily build websites of various types without needing any sort of programming knowledge.

Prerequisites

If you’re going to follow along, the prerequisites are basically identical to my previous post:

• An up to date Debian 11 install that has a LEMP stack installed, and you have full root access to. Regardless of your hardware/software, you’ll want at least 512MB of free RAM. You’ll also want to use something like SSH so you can copy and paste commands.
• Some Linux command line experience.
• I’m going to assume that you’ll want to put your WordPress instance on the internet for people to visit, so you’ll also need access to whatever firewalls your server is behind, and information like your public IP address. You’ll also want a domain name (Unless if you want to make your visitors remember an IP address for whatever reason).

Like I said in my previous post, I would recommend using a VPS (Virtual Private Server) as opposed to opening up a server at your home to the internet. If you’re looking for a VPS, there’s many good and cheap options, but I personally use Vultr (Referral plug because why not?). There’s a lot of security risks involved with exposing parts of your network to the internet, especially if your server isn’t properly patched, or if you misconfigure your firewalls. You also might run into roadblocks with stuff like CGNAT (Carrier Grade NAT) or your ISP blocking ports, which makes it difficult or impossible to port forward. Plus if you have crappy internet, it can make a pretty poor experience for your visitors.

Downloading WordPress

There’s a few different ways of downloading WordPress to your server, but I prefer using the command line since it’s more convenient in my opinion.

First, install wget and unzip:

sudo apt install wget unzip

Download the WordPress zip file:

wget https://wordpress.org/latest.zip

Unzip the file to /usr/share/nginx:

sudo unzip latest.zip -d /usr/share/nginx

And finally, change the owner of /usr/share/nginx/wordpress to the Nginx user (Don’t be like me and forget this step then wonder why doing anything gives me access denied errors):

sudo chown -R www-data:www-data /usr/share/nginx/wordpress

Don’t forget to remove the downloaded ZIP file so it doesn’t take up space on your server:

rm latest.zip

Connecting WordPress to MariaDB

You’ll need to create a dedicated database and database user for WordPress. Since I’m not familiar with MySQL commands, I’ll show you how to do it through phpMyAdmin.

Once you’ve logged in as a root user, click the New button in the left side bar:

Enter a database name, and then click Create:

Click the phpMyAdmin logo in the top left corner to return to the main screen, then select the User accounts tab:

Under new, click Add user account:

Enter a username and password, and click Go on the bottom right side of the page. Make sure to take note of this information since you’ll need this for creating wp-config.php:

After the user has been created, select the Database tab, and under Database-specific privileges, enter the name of the database that you’ve created (The name of mine is wordpress), then click Go:

Select the Check all checkbox next to Database-specific privileges, then click go:

After that, you should now have a MariaDB database and user for WordPress, and you can also modify WordPress’s databases directly by logging into the WordPress user (This has saved me a few times when I’ve changed the wrong setting and locked myself out).

Creating and Editing wp-config.php

Now that you’ve set up a MariaDB database and user for WordPress, it’s now time to make WordPress use them. Navigate to /usr/share/nginx/wordpress and rename wp-config-sample.php to wp-config.php.

Navigate to the following lines (Starting line 22), and replace the database name, username, and password with the one’s that you’ve just created:

/** The name of the database for WordPress */
define( 'DB_NAME', 'database_name_here' );

/** Database username */
define( 'DB_USER', 'username_here' );

/** Database password */
define( 'DB_PASSWORD', 'password_here' );

There are many other options in this file, but these should be the only changes that you need to make.

Creating an Nginx Server Block

Save the below server block in /etc/nginx/conf.d as wordpress.conf. This also happens to be the same server block that I use. For testing purposes, use your servers IP address for server_name, but you’ll be changing it to your domain name later:

server {
  listen 80;
# You can safely remove the below line if your server doesn't support IPv6
  listen [::]:80;
  server_name 12.34.56.78;
  root /usr/share/nginx/wordpress/;
  index index.php index.html index.htm index.nginx-debian.html;

  location / {
    try_files $uri $uri/ /index.php;
  }

   location ~ ^/wp-json/ {
     rewrite ^/wp-json/(.*?)$ /?rest_route=/$1 last;
   }

  location ~* /wp-sitemap.*\.xml {
    try_files $uri $uri/ /index.php$is_args$args;
  }

  error_page 404 /404.html;
  error_page 500 502 503 504 /50x.html;

  client_max_body_size 999G;

  location = /50x.html {
    root /usr/share/nginx/html;
  }

  location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    include snippets/fastcgi-php.conf;

    # Add headers to serve security related headers
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header X-Permitted-Cross-Domain-Policies none;
    add_header X-Frame-Options "SAMEORIGIN";
  }

  #enable gzip compression
  gzip on;
  gzip_vary on;
  gzip_min_length 1000;
  gzip_comp_level 5;
  gzip_types application/json text/css application/x-javascript application/javascript image/svg+xml;
  gzip_proxied any;

  # A long browser cache lifetime can speed up repeat visits to your page
  location ~* \.(jpg|jpeg|gif|png|webp|svg|woff|woff2|ttf|css|js|ico|xml)$ {
       access_log        off;
       log_not_found     off;
       expires           30d;
  }

  # disable access to hidden files
  location ~ /\.ht {
      access_log off;
      log_not_found off;
      deny all;
  }

}

Once you’ve created the file, run the following command to test it:

sudo nginx -t

If there’s no errors, restart nginx so it can pick up the new server block:

sudo systemctl restart nginx

Change Max Upload Size

Since the max upload size by default is only 2MB, chances are you’ll want to increase it. Open /etc/php/7.4/fpm/php.ini in a text editor.

Scroll down to line 694, and change it to something larger. I personally have mine set to 999G so I don’t have to worry about any sort of limits, but if you’re going to allow users to upload content, you probably want to change it to something smaller:

post_max_size = 8M

Scroll down to line 846, and change it to something bigger. I also have this set to 999G, but like I said, you might want to keep it smaller if you’re allowing users to upload content:

upload_max_filesize = 2M

After you’re done making your changes, restart PHP:

sudo systemctl restart php7.4-fpm

Basic WordPress setup

I don’t plan on going into detail, but I’ll be showing the basics. Navigate to your servers IP address, and you should be redirected to the WordPress setup screen.

Getting an Nginx Welcome Screen

A problem that you might run into (At least one that I’ve run into a few times) is getting the Nginx welcome screen instead of being redirected to the WordPress install like in the screenshot. As a temporary workaround to get WordPress installed, you might be able to navigate to your_ip_address/wp-admin/install.php just to get WordPress installed, but you’ll still get the Nginx welcome screen if you just go to your servers IP address without a path:

First, try just simply rebooting your server. Rebooting my server has fixed this issue after I’ve determined that everything was setup correctly.

Next, check /etc/nginx/conf.d to see if there’s any server blocks that you don’t need, or one’s that are also using port 80. Remove any unneeded server blocks or change the ports that they’re using then run sudo systemctl restart nginx. You can also remove the welcome page from /usr/share/nginx/html to see what happens.

Lastly, check the logs for PHP and Nginx by running sudo systemctl status nginx and sudo systemctl status php7.4-fpm, or by checking their log files in /var/log. Usually they’ll tell you if something weird is going on.

After running through these steps, I would recommend rebooting your server again to ensure that everything has been restarted.

Once you’ve gotten to the WordPress install screen, select your language, and click Continue:

Enter a website name, username, password, and email address. I would also recommend checking the box to discourage search engines from indexing your website, then unchecking it once you’re ready to launch it. Click Install WordPress:

Once WordPress has been installed (Which should happen very quickly), click Log In to be redirected to the login page, then login using the login information that you entered during the install process:

Updating and Configuring WordPress

Before using WordPress, I would recommend installing updates. Under Dashboard in the left side bar, click Updates:

Depending on how long ago you download WordPress, there might be a few updates. But for me I only needed to update one plugin. Click the checkbox next to Select All, and then click update (Do this for themes as well if there’s updates available):

I would also recommend switching to security updates only for better stability, and also so your WordPress install doesn’t decide to randomly update to a new major version and cause a mess (cough Windows cough):

DNS and HTTPS

Just as a disclaimer, in this section my knowledge and experience is a little thin in some spots, so some stuff may not be explained all that well or correctly, but I’m open to feedback in the comments.

If you’ve made it this far, then congratulations! You’ve got yourself a mostly working WordPress install. However, it’s not all that secure because there’s no HTTPS, and you probably have a domain name that you want to use. Before doing this, make sure that your server is accessible to the internet by opening the necessary ports (80 and 443) on your firewalls, and also port forward if needed. I highly recommended doing some trial and error to ensure that your server is accessible while being secure, and I’ll be covering security in more detail in a future post. If you’re behind Cloudflare, you only need to open those ports to Cloudflare’s IP ranges once everything is set up.

First, select settings in the left side bar, and change WordPress Address and Site Address to https://your_domain__name.com like in the screenshot:

Just note that once you click Save Changes at the bottom of the screen, you will be locked out of your site because WordPress will only allow you to access your site from your domain name, and since you don’t have that set up yet, your site isn’t accessible. If you do need to change the URLs back for whatever reason, log into MariaDB with your WordPress user, open the WordPress database, open the wp_options table, and change siteurl and home to the previous values. You can also do this through phpMyAdmin.

DNS Records

The first thing that you’ll want to do is create a DNS record for your web server. This will vary depending on the domain registrar, so check their documentation before proceeding. You’ll most likely need an A DNS record for your server, a CNAME record so if someone types in www.your_domain.com, it will resolve to your_domain.com, and a AAAA record if your server supports IPv6. Here’s what my records look like in Cloudflare for example:

If your server is proxied behind Cloudflare like mine is, you don’t need an AAAA record. This is because your domain will resolve to Cloudflare’s IP addresses instead, and Cloudflare will forward the requests to your server.

It may take a while for your DNS records to propagate, so don’t panic if your browser fails to resolve your domain and nslookup or dig don’t return anything. I recommend waiting a few hours and turning the TTL down, then turning it back up once your domain resolves.

HTTPS

Once your DNS records have propagated and your domain name resolves, it’s now time to set up HTTPS. If you try visiting your website now, you’ll probably get a different error. This is because even though WordPress is listening for HTTPS visitors and you typed https into your browser, your server doesn’t have a certificate installed, and Nginx isn’t listening on port 443.

First, open /etc/nginx/conf.d/wordpress.conf in a text editor, go to that same server_name line from earlier, and and change it to the following (Replacing example.com with your actual domain name):

server_name example.com www.example.com;

Next, test the configuration file:

sudo nginx -t

And finally, restart Nginx:

sudo systemctl restart nginx

To generate an HTTPS certificate, first you’ll install Certbot:

sudo apt install certbot python3-certbot-nginx

Next, generate a certificate by running the following command, replacing the example domains with yours, and the email address that you used to register the domains:

sudo certbot --agree-tos --nginx --redirect --hsts --staple-oscp --email email@example.com -d example.com,www.example.com

And finally, now your website should hopefully be accessible. If it is, then that means I wrote this section correctly (And you correctly followed the instructions). You might need to restart your server or Nginx before your website is accessible over HTTPS.

If you followed this post correctly (And I didn’t screw anything up), then congratulations! You should now have a fully working WordPress website that’s ready for you to start building. In a couple of upcoming posts, I’ll be going over my personal choices for WordPress plugins, and also how to take advantage of Cloudflare’s features and Fail2ban with WordPress. Feel free to leave a comment if you have any problems or suggestions, and I’ll try my best to help.

Part 3: My Top Picks for WordPress Plugins (Comments, Security, Email) – Building a WordPress Blog Part 3

References

Most of the content in this post is from my own knowledge or experience, but I did still reference some documentation and tutorials. These are the only ones that I can think of off of the top of my head.

WordPress’s Documentation

LinuxBabe’s Tutorial

The post Installing WordPress with Nginx, MariaDB, and PHP7.4 (LEMP Stack) on Debian – Building a WordPress Blog Part 2 appeared first on Alex's Home Network.

I have written an updated and much better version of this guide. I’m primarily keeping this post up for archival purposes, and if anyone wants to reference it for whatever reason. If you’re looking to follow this guide, follow the one I linked below instead.

New guide: https://alexshomenetwork.com/installing-wordpress-on-debian-13/

Old Post

In this blog post I’ll show you how I installed a LEMP stack on Debian 11, but this post should apply to most distros based on Debian. I won’t go too much into detail about what these services do, but in a nutshell, Nginx is a web server, MariaDB is a database, PHP is a server-side scripting language, and it all comes together to power dynamic websites, including CMS’s (Content Management Systems) like WordPress. LEMP stands for Linux, Nginx, MariaDB or MySQL, and PHP. I’ll also show how to install phpMyAdmin, which will allow you to manage MariaDB through a web interface.

Prerequisites

If you plan on following along, you’ll need the following:

• An up to date Debian 11 install running on your hardware/software of choice with full root access (You don’t need many resources, but I would recommend at least 512MB of available RAM).
• Some Linux command line experience.
• If you plan on putting it on the internet, then you’ll also need access to your firewall, your public IP address, and a domain name.
• I would recommend enabling SSH since you’ll be able to copy-paste commands, and it’ll make managing your server easier. However, do not do this if you don’t know how to firewall a server off. If you open SSH to the internet and an attacker guesses your login, then they will have full root access to your server.

You really don’t need much for this project, however, I would recommend using a VPS (Virtual Private Server) instead of directly exposing parts of your network to the internet. Not only is it more secure, but you don’t have to worry about stuff like CGNAT (Carrier-Grade NAT) or poor upload speeds (Like I do, thanks Xfinity). I personally use Vultr (What’s a good blog post without a referral plug?), but there’s plenty of good options out there.

Installing Filebrowser (Optional)

I cannot stress this enough, but if you don’t know how to properly firewall off a server, skip this step. If it’s not properly firewalled off, an attacker could guess your login info and gain full access to your server’s filesystem. If you do know what you’re doing, a web-based file manager like Filebrowser makes life a lot easier when editing config files.

However, if you’re using SSH on your server, you can also skip this step (Unless if you want to manage config files through a web interface) since you can leverage SFTP (SSH File Transfer Protocol) through FileZilla. It might not be as user friendly, but this will eliminate the need of having more services running and ports open on your server.

To install Filebrowser, simply copy-paste the following command (Make sure you install curl first):

curl -fsSL https://raw.githubusercontent.com/filebrowser/get/master/get.sh | sudo bash

Filebrowser has various options, but to run Filebrowser and give it full access to your filesystem, replace the example IP address and the port number with yours (If you don’t specify it, then port 8080 will be used), and run the following command:

sudo filebrowser -r / -a 12.34.56.78 -p 1234

You should now be able to access Filebrowser by typing in your_ip_address:your_port_number in to your web browser. If you can’t access it, check to make sure that the IP address you entered is correct (Or try entering 0.0.0.0, but I’ve found that it doesn’t always work), and make sure that any firewall that your server is behind is allowing the port you specified. Some Linux distros may include a firewall like ufw or iptables by default, but Debian does not.

Securing Filebrowser

Once you’ve accessed the login page, use admin for the username and password. You’ll want to change this from the defaults.

Over on the left side of the screen, select Settings:

Select User Management:

Select the pencil icon:

Enter a new username and password of your choice:

Then finally, select Save at the bottom of the page:

Making Filebrowser a Service

Since remembering the command for Filebrowser can be difficult and you might want it to run in the background, it’s possible to make it a systemd service by creating a file in /etc/systemd/system/filebrowser.service with your favorite text editor, and adding the following lines (Replacing Filebrowser Command with your Filebrowser command, obviously):

[Unit]
Descirption=Filebrowser

[Service]
ExecStart=Filebrowser Command

[Install]
WantedBy=multi-user.target

Now you can run Filebrowser in the background simply by typing in sudo systemctl start filebrowser, or allow it to run at startup by typing in sudo systemctl enable filebrowser.

Installing Nginx

To install Nginx, run the following command

sudo apt install nginx

Start Nginx by running the following command:

sudo systemctl start nginx

And then check its status:

sudo systemctl status nginx

If Nginx appears to be running, press q on your keyboard if the command didn’t quit, then type the IP address of your server into your web browser’s address bar. You should see a screen that looks like this:

Run the following command to allow Nginx to run at startup:

sudo systemctl enable nginx

Then make the Nginx user (www-data) the owner of the web directory:

sudo chown -R www-data:www-data /usr/share/nginx/html

Nginx Automatic Restart

If Nginx is killed, you’ll need to manually run sudo systemctl restart nginx, but it’s possible to automate this process. First create the following directory:

sudo mkdir -p /etc/systemd/system/nginx.service.d/

Create and open the following file with your favorite text editor:

/etc/systemd/system/nginx.service.d/restart.conf

Add the following lines (You can replace the highlighted text with whatever time you want, but don’t make it too short):

[Service]
Restart=always
RestartSec=5s

Then finally run the following command so systemd will pick up the changes:

sudo systemctl daemon-reload

You can test that Nginx will be automatically restarted by running sudo pkill nginx, wait 5 seconds (Or however long you specified), and then run sudo systemctl status nginx to see if Nginx was restarted.

Troubleshooting

If Nginx fails to start, the output of sudo systemctl status nginx should show some sort of error. If it doesn’t, then check the error log under /var/log/nginx/error.log.

If Nginx appears to be running just fine, but you’re still unable to connect, check to make sure that port 80 is permitted in your firewall.

Installing MariaDB

Run the following command to install the MariaDB client and server:

sudo apt install mariadb-server mariadb-client

Start MariaDB:

sudo systemctl start mariadb

Check its status:

sudo systemctl status mariadb

And if it’s running and there’s no errors, run the post installation security script:

sudo mysql_secure_installation

Select yes (Or just press enter) for all of the steps and follow the prompts.

Finally, allow MariaDB to run at startup:

sudo systemctl enable mariadb

Installing PHP7.4

Depending on what you’re trying to run, you might need different PHP extensions than what I’ll list. The following command will install PHP7.4 along with the extensions that I use for WordPress:

sudo apt install php7.4 php7.4-bz2 php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-xml php7.4-zip php7.4-imagick

Start PHP:

sudo systemctl start php7.4-fpm

Check its status:

sudo systemctl status php7.4-fpm

And if it’s running, then enable it to run at startup:

sudo systemctl enable php7.4-fpm

Installing phpMyAdmin (Optional)

phpMyAdmin is very useful for managing MariaDB (Or any other compatible database), so I would recommend installing it. However, like some of the other tools I recommended, only do this if you can properly firewall it off. If it’s not properly firewalled off, than an attacker could easily gain access to your MariaDB database, thus the data of whatever relies on it.

To start the installation process of phpMyAdmin, run the following command:

sudo apt install phpmyadmin

During installation, various prompts will be displayed. The first prompt will ask you what web server should automatically be configured, but if you’re using Nginx like me, press the tab key, then press enter:

The second prompt will ask you if you want to use dbconfig-common to automatically configure the database. Press enter to select yes:

The last prompt will ask you to enter a password for the phpmyadmin user. Enter a password, then press enter. You’ll be prompted again to confirm your password:

Create an Nginx Server Block

Since the phpMyAdmin setup didn’t include an option to automatically configure Nginx, we’ll have to do it ourselves. Create a file in /etc/nginx/conf.d/phpmyadmin.conf using your favorite text editor, and add the following lines:

server {
  #Change the highlighted port numbers.
  listen 1234;
  #The line below is optional. You don't need it if your server doesn't support IPv6.
  listen [::]:1234;
  server_name _;
  root /usr/share/phpmyadmin/;
  index index.php index.html index.htm index.nginx-debian.html;

  access_log /var/log/nginx/phpmyadmin_access.log;
  error_log /var/log/nginx/phpmyadmin_error.log;

  location / {
    try_files $uri $uri/ /index.php;
  }

  location ~ ^/(doc|sql|setup)/ {
    deny all;
  }

  location ~ \.php$ {
    fastcgi_pass unix:/run/php/php7.4-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    include snippets/fastcgi-php.conf;
  }

  location ~ /\.ht {
    deny all;
  }
}

Run the following command to have Nginx test your config file:

sudo nginx -t

If there’s no errors, restart Nginx:

sudo systemctl restart nginx

Access phpMyAdmin by typing in your_ip_address:your_port_number into your web browser. If everything works correctly, then you should see the phpMyAdmin login screen. You can either use root as the username with the password that you chose while installing MariaDB, or use phpmyadmin as the username and the password that you chose while installing phpmyadmin. You can also use the login of any other database user that you might have.

If you’ve decided to follow this post and you’ve followed everything correctly (Or I didn’t screw up), then congratulations. You should now have Nginx, MariaDB, and PHP7.4 installed and ready to host your dynamic website. Read part 2 where I’ll show you how to install WordPress on top of this LEMP stack. I hope that you enjoyed reading this post, and hopefully you learned something too. If you have any problems, feel free to leave a comment, and I’ll try my best to help you (I can’t guarantee anything though).

Part 2: Installing WordPress with Nginx, MariaDB, and PHP7.4 (LEMP Stack) on Debian – Building a WordPress Blog Part 2

References

Here’s all of the references I used, and two of them are arguably better tutorials.

LinuxBabe’s tutorial on how to install a LEMP stack on Ubuntu

LinuxBabe’s Tutorial on How to Install phpMyAdmin

Filebrowser installation and Documentation

The post Installing Nginx, MariaDB, and PHP7.4 (LEMP Stack) on Debian – Building a WordPress Blog Part 1 appeared first on Alex's Home Network.